# System design cheat sheet: how Uber finds your driver

Copy-paste this into Claude, ChatGPT or any AI assistant.

---

Create a one-page cheat sheet titled "How Uber Finds Your Driver: System Design Cheat Sheet" for software engineers preparing for system design interviews. Make it a clean, printable single page (or a shareable web page), skimmable in 2 minutes, with short bullets and simple diagrams.

Sections:
1. The question: "Design ride matching: a rider taps Request, find a nearby driver in seconds."
2. The trap: comparing every rider to every driver (riders × drivers distance checks) and why it collapses at peak time (e.g. New Year's Eve). Label any numbers as examples.
3. Requirements: functional (match a nearby available driver, track live locations) and non-functional (low latency, high write throughput from location pings, handle demand spikes, availability over strict consistency for locations).
4. Trick 1, latest location only: drivers ping every few seconds; keep only the newest location per driver in an in-memory store (e.g. Redis); old pings are discarded or sent to cold storage for analytics.
5. Trick 2, spatial index: split the map into cells (geohash or grid); index drivers by cell; on Request, search the rider's cell plus the ring of neighbouring cells, then rank candidates by ETA on the road network, not straight-line distance. Explain how expanding the ring works when no drivers are found.
6. Trick 3, one offer at a time: offer the best candidate, wait for accept/timeout, then move to the next; lock the driver so two riders can't get the same car (idempotent offers, driver state machine: available → offered → on trip).
7. The twist, hexagons (H3): Uber's open-source hexagonal grid (2018). With squares, diagonal neighbours are farther than side neighbours; with hexagons all 6 neighbours are equidistant, so "nearby" is consistent. H3 has multiple resolutions (bigger/smaller cells).
8. Bonus, surge pricing: count riders (demand) vs available drivers (supply) per hexagon; when demand outruns supply, raise the price multiplier for that area.
9. Simple architecture diagram (text boxes and arrows): Driver app → Location service → In-memory geo index; Rider app → Matching/Dispatch service → Offer service → Driver app; Pricing service reads per-hexagon supply/demand.
10. Back-of-the-envelope: show how to estimate location writes per second (drivers online ÷ ping interval), clearly labelled as an example.
11. Follow-up questions interviewers ask, with a 1–2 line answer each:
   - What if a driver's phone stops sending pings?
   - How do you handle a hot cell downtown at rush hour (sharding by cell)?
   - Geohash vs H3 vs quadtree: when would you pick each?
   - How do you prevent double-booking a driver across servers?
   - How do you match pooled/shared rides?
   - How does ETA differ from straight-line distance, and where does it come from?
   - What happens when a data centre fails mid-trip?
12. "Say this in your interview": a 4–5 sentence summary answer.

Rules: accurate facts only (don't invent Uber's exact internal numbers like ping interval or offer timeout; say "every few seconds" / "a short timeout"), plain English, define jargon once, no fluff. Footer: "From @medbouhezza · follow for one system design question a day".

---

By Mohamed Bouhezza (@medbouhezza) · NOQTA