Ride Sharing

Same startup, same engineer #4. Tenth Monday.

Your CTO drops by. "Users love everything we've built. Now the ambitious ask — we want to add a ride-hailing feature. A rider requests, a driver accepts, GPS tracks the trip, payment happens automatically. Ship an MVP in 12 weeks."

She pauses. "For context — Uber processed $162 billion in gross bookings in 2024 across ~161M monthly active platform consumers (MAPCs — Uber's official metric, not MAU). They invented H3, a hexagonal geospatial index that's now open-source and used by anyone doing serious geo work. And their DeepETA model — a deep neural network that predicts trip ETAs — reduced error by 50% vs classical routing algorithms. If we're going to compete, we need to understand what makes ride-sharing fundamentally different from anything else we've built."

Here's the paradigm shift:

URL Shortener, Slack, Instagram, Twitter, WhatsApp, Netflix, YouTube, Dropbox — all had bounded, predictable request patterns. A URL redirect. A message. A feed load. A video play. A file upload. These are IDENTICAL from a systems perspective — they're I/O + compute over a predictable payload.

Ride-sharing is a real-time bipartite matching problem — riders and drivers exist as continuous, GPS-updating streams, and every 30 seconds you're solving "assign N rider requests to M drivers optimally." That's operations research colliding with distributed systems. It's the hardest system-design interview problem by a wide margin.

Uber's answer was to (1) build H3 — a hexagonal geospatial index so every location snaps to a discrete cell, making queries O(1) instead of O(N) (Uber Engineering blog: H3); (2) build DISCO — the Dispatch Optimization Service that does batched bipartite matching every 30s (Uber talk 2016); (3) build DeepETA — a transformer-based ETA predictor with 50% lower error than classical routing (Uber Engineering blog: DeepETA); and (4) build Ringpop — their scalable sharding library for consistent hashing at scale (Uber Engineering blog: Ringpop).

If your interview answer doesn't cite at least H3 and DISCO, you'll fail. Naming DeepETA and Ringpop signals senior-level awareness.

The real 2024 numbers

• ~161M MAPCs (Monthly Active Platform Consumers — Uber's official metric, Q4 2024 earnings)
• ~$162B Gross Bookings 2024 — up 21% YoY
• ~11B trips in 2024
• ~7M active drivers globally
• ~30 second dispatch window — DISCO batched matching cadence
• ~50% reduction in ETA error vs classical routing via DeepETA (Uber Engineering, 2022)
• H3 resolution 9 hexagon (~174m across) — the primary lookup unit for driver-nearest queries
• Multi-region active-active — regional failover in <60s

Interview soundbite: "Uber at 161M MAPCs is a real-time bipartite matching problem, not a request-response problem. Every 30 seconds, DISCO solves 'assign these N rider requests to these M drivers optimally' using H3 hexagonal geo-cells for O(1) proximity queries. DeepETA gives per-trip time-of-arrival predictions with 50% lower error than classical Dijkstra. If it feels like operations research, that's because it is."

The whole journey at a glance

Every 10× in drivers×riders forces a fundamentally different matching strategy:

text
    ═══════════ UBER ARCHITECTURE ACROSS 4 SCALES ═══════════

    L4 (10K users)     L5 (10M users)     L6 (100M users)         L7 (161M MAPCs, global)
    PostGIS + greedy   H3 index + DISCO    Multi-city + DeepETA   Global multi-region
    12 weeks · $500/mo 6 months · $50K/mo  18 months · $2M/mo     ongoing · $500M/yr

    ┌────────┐         ┌────────┐         ┌── Regional ALBs ───┐  ┌── 20+ regions ───────┐
    │Rider   │         │Rider   │         │  city-level        │  │  anycast + BGP        │
    │Driver  │         │Driver  │         │  routing           │  │  Uber own edge        │
    │apps    │         │apps    │         └─┬──┬──┬──┬─────────┘  └──┬──┬──┬──┬──────────┘
    └───┬────┘         └───┬────┘           │  │  │  │              │  │  │  │
        │                  │              ┌─▼──▼──▼──▼─────┐        │  │  │  │
     ┌──▼───┐           ┌──▼──┐           │  Regional API  │    ┌───▼──▼──▼──▼──────────┐
     │ ALB  │           │ ALB │           │  + DISCO svc   │    │ Global API Gateway    │
     │ WSS  │           │ WSS │           │  + Trip svc    │    │ + Ringpop sharding    │
     └──┬───┘           └──┬──┘           └───┬──────┬─────┘    │ + Envoy + gRPC        │
        │                  │                  │      │           └──┬──┬──┬──┬──────────┘
     ┌──▼──────┐       ┌───▼─────────┐    ┌───▼──────▼───┐          │  │  │  │
     │ Node.js │       │ Go / Java   │    │  DISCO       │       ┌──▼──▼──▼──▼──────────┐
     │ monolith│       │ 100+ svcs   │    │  batched     │       │ DISCO (per-city)     │
     │ + PG    │       │ + Ringpop   │    │  matching     │      │ Global bipartite     │
     │ + WS    │       │ + Kafka     │    │  every 30s   │       │ optimization         │
     └──┬──────┘       └───┬─────────┘    └───┬───────────┘       │ + DeepETA           │
        │              ┌───▼──┐           ┌───▼──────────┐        │ transformer         │
        │              │Redis │           │Cassandra +   │        │ prediction           │
        │              │GEO   │           │Redis GEO     │        └──┬──┬──┬──┬─────────┘
        │              │+ hot │           │+ H3 index    │           │  │  │  │
        │              └───┬──┘           └───┬──────────┘        ┌──▼──▼──▼──▼─────────┐
        │                  │                  │                   │ Cassandra multi-DC   │
     ┌──▼───┐          ┌───▼─┐            ┌───▼──────────┐       │ + Redis GEO regions  │
     │Postgr│          │Postgr│            │Sharded Post- │       │ + Kafka streams for  │
     │+ Pos-│          │+ shar│            │gres + Schem- │       │ trip events          │
     │tGIS  │          │d by  │            │aless (Uber's │       │ + Manifold (S3-like) │
     │(driv │          │user  │            │KV store)     │       └──┬───────────────────┘
     │+ trip│          │_id   │            └──────────────┘          │
     │+ user)          │+ RF=2│                                   ┌──▼───────────────────┐
     └──────┘          └──────┘                                   │ Schemaless (Uber's   │
                                                                  │ MySQL-backed KV       │
                                                                  │ wraps MySQL          │
                                                                  │ ~40 PB per region)   │
                                                                  └───────────────────────┘

    ↑                  ↑                  ↑                       ↑
   Boring           H3 + DISCO enter.   Multi-city + DeepETA    Global multi-region.
   PostgreSQL +     Batched matching    ML routing + Schemaless  Ringpop consistent hash.
   PostGIS + WS.    every 30s.          MySQL-backed KV.         DISCO globally.
                    Ringpop sharding.

   Chapter 5      Chapters 6+6.5      Chapter 7+7.5              Chapter 8
   walks          walks through       walks through DeepETA      walks through 161M
   through        H3 index + DISCO    + Schemaless + multi-      MAPCs, global topology,
   L4 MVP         batched matching    city topology              and business economics

  Key insight: Ride-sharing is a REAL-TIME BIPARTITE MATCHING problem, not a
  request-response problem. Every 30s, DISCO assigns N riders to M drivers
  optimally, using H3 hexagons for O(1) geo queries, DeepETA for trip time
  prediction, Ringpop for consistent-hash sharding. This shape is unique to
  ride-sharing. Every architecture decision is subordinated to the 30s
  matching cadence.

The same 4 tiers as clean architecture diagrams

L4 · 10K users · PostGIS + greedy match · $500/mo · 12 weeks:

L5 · 10M users · H3 + DISCO batched match · $50K/mo · 6 months:

L6 · 100M users · Multi-city + DeepETA · $2M/mo · 18 months:

L7 · 161M MAPCs · Global multi-region + Ringpop · $500M/yr:

Why every 10× breaks the architecture

1. The geo-index changes. L4 = PostGIS. L5+ = H3 hexagonal cells because H3 gives O(1) proximity queries via hex-neighbor lookup instead of O(N log N) k-nearest-neighbor. This is Uber's biggest engineering contribution to the industry. Reference: Uber H3 blog + open-source.

1. Matching changes. L4 = greedy "closest driver". L5+ = batched bipartite optimization. Every 30s, DISCO solves an assignment problem across ALL pending riders and available drivers, minimizing total ETA. Greedy is 10-30% worse. Reference: Uber DISCO talk 2016.

1. ETA prediction changes. L4 = "distance ÷ average speed". L6+ = deep-learning model on 100s of features (weather, traffic, time-of-day, driver behavior). DeepETA reduced Uber's ETA error by 50%. Reference: Uber DeepETA blog.

The 3 senior insights before we start Chapter 1

1. H3 is Uber's most influential engineering contribution. Every serious geo-based system (Ola, Grab, Lyft, Instacart, DoorDash) uses H3 hexagons or equivalent. Not lat/lng. Not quadtrees. Not R-trees. Hex cells because they have uniform-distance neighbors — 6 neighbors all equidistant, unlike squares. Reference: H3 GitHub.

1. DISCO's 30-second batching cadence is the interview signal. Naive answers say "match immediately". Senior answers say "batch every 30s and solve optimally, because greedy matching leaves 10-30% efficiency on the table when driver density is high enough that batching converges."

1. Ringpop consistent hashing is Uber's sharding pattern. Not vanilla consistent hashing. Not database sharding. Ringpop is application-level consistent-hash routing + membership + failure detection, all in one library. Reference: Ringpop GitHub.

Chapter map for the journey ahead

• Chapter 1 — Requirements (rider, driver, payment, cancellation, surge)
• Chapter 2 — Capacity estimation (161M MAPCs, 11B trips/year, 30s dispatch)
• Chapter 3 — API design (request ride, driver actions, trip lifecycle)
• Chapter 4 — Data model (users, drivers, trips, payments — with state machines)
• Chapter 4.5 — H3 hexagonal geospatial indexing: how it works + why it wins
• Chapter 5 — L4 MVP: PostGIS + greedy match + WebSocket. Up to 10K users
• Chapter 6 — L5: DISCO batched matching + H3 + Ringpop sharding
• Chapter 6.5 — The batched-matching algorithm: bipartite optimization every 30s
• Chapter 7 — L6: Multi-city topology + DeepETA transformer + Schemaless
• Chapter 7.5 — DeepETA: how a transformer predicts arrival times
• Chapter 8 — L7: 161M MAPCs + global regions + surge + fraud + $500M/yr infra
• Chapter 9 — Failure modes: driver-supply shortage, matching timeout, GPS drift, fraud
• Chapter 10 — Trade-off matrix (Uber vs Lyft vs DoorDash vs Grab)
• Chapter 11 — Interview masterclass: 45-min mock, questions to ask
• Chapter 12 — Defense: the 20 hardest interview questions on Uber

Ready? Chapter 1 next: what did the CTO actually ask for?