Comment Uber trouve ton chauffeur.

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.

1. 01

   The question

   "Design ride matching: a rider taps Request, find a nearby driver in seconds."

2. 02

   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. 03

   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. 04

   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. 05

   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. 06

   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. 07

   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. 08

   Bonus, surge pricing

   count riders (demand) vs available drivers (supply) per hexagon; when demand outruns supply, raise the price multiplier for that area.

9. 09

   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. 10

    Back-of-the-envelope

    show how to estimate location writes per second (drivers online ÷ ping interval), clearly labelled as an example.

11. 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. 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".