Design a Cab Booking System

Problem Design a cab booking system (Uber-style): riders request trips, nearby drivers are matched, locations stream in real time, trips run a lifecycle, and pricing includes surge.

Functional requirements

• Rider: request ride (pickup/destination), see nearby cars + ETA, live trip tracking, fare estimate. Driver: go online, receive/accept offers, navigate, complete trip. Trip lifecycle: requested → matched → arriving → in-progress → completed/cancelled.

Non-functional requirements

• Matching latency a few seconds; location ingest is the write-heavy hot path (10^5+ drivers × update every ~4 s); trip state must never be lost; regional availability during spikes.

Key components

• Location service: driver GPS ingest → in-memory geo index (geohash/H3 cells or Redis GEO), short-TTL data.
• Matching/dispatch service: query nearby cells, rank candidates (distance/ETA, driver rating, acceptance), offer with timeout → next candidate.
• Trip service: durable state machine (DB), event-driven updates to rider/driver apps via persistent connections/push.
• Pricing service: base fare + surge from supply/demand per zone (periodically computed multipliers).

Deep dives / trade-offs

• Geo indexing choice and cell-size trade-off; edge cells requiring neighbor-cell search.
• Avoiding double-dispatch: lock/lease a driver during an offer window.
• Surge fairness/stability (hysteresis so multipliers don't flap); location write path scaling via partitioning by region.