Ride Sharing System
Do workloads bilkul alag hain aur inhe alag services banana zaroori hai. LOCATION INGESTION write-heavy hai — 10 lakh drivers har 4 second location bhejte hain, matlab ~250K writes/sec. Ye main DB mein nahi ja sakta; in-memory geo store (Redis GEO) mein jaata hai aur history alag se Kafka ke through cold storage mein.
MATCHING read path hai. Earth ko grid cells mein baanto (geohash ya S2 cells) — nearby drivers dhoondhna ek cell lookup ban jaata hai, poora scan nahi. Matching service driver ko offer bhejti hai timeout ke saath, accept na kare to next. Ride state (REQUESTED → ASSIGNED → IN_PROGRESS → COMPLETED) durable store mein rehti hai.
// Write path — 250K writes/sec, DB ko chhuta hi nahi
Driver app → Location Service → Redis GEO (live position)
→ Kafka → cold storage (trip history)
// Read path — matching
Rider request → Matching Service
→ GEOSEARCH (3 km radius, ~10 candidates)
→ ranking → offer with 15s timeout → next driver- Location ingestion (write-heavy) aur matching (read) alag services
- Geohash/S2 cells se nearby lookup — poora scan kabhi nahi
- Live position in-memory, history Kafka se cold storage mein
GEOHASH earth ko grid mein baantkar har cell ko ek string deta hai — prefix jitna lamba, cell utna chhota. Simple hai aur Redis mein built-in support hai. Problem: cell boundaries par do nazdeek points ke geohash bilkul alag ho sakte hain, isliye padosi cells bhi check karne padte hain.
S2 (Google) earth ko sphere par map karta hai aur distortion kam rakhta hai; QUADTREE density ke hisaab se adaptive cells banata hai (shehar mein chhote, jungle mein bade). Interview ke liye geohash bolna aur uski boundary limitation batana kaafi hai.
// Boundary problem — padosi cells bhi dekhne padte hain
GEOSEARCH drivers:live FROMLONLAT :lng :lat BYRADIUS 3 km ASC
// Redis ye andar hi handle kar leta hai; khud implement karo to
// 8 neighbouring cells manually check karni padengiRide ek state machine hai jiski state DURABLE store mein rehni chahiye — driver ka phone band ho jaaye to bhi ride ka record rahe. Live location ephemeral hai (Redis), par ride state persistent (DB).
Ride complete hone par fare calculate hoti hai aur payment charge hota hai. Payment fail hone par ride ko "completed but unpaid" mark karo — ride ko rollback mat karo, wo physically ho chuki hai. Ye batana real-world thinking dikhata hai.