Design a Global Ride-Sharing Dispatch System

Design Uber already solved the core matching problem — geohashing nearby drivers, locking one driver to one rider. This problem deliberately reuses that solution rather than re-deriving it, and asks a different, harder question on top: what changes when the same service has to run simultaneously across dozens of countries and continents, survive an entire region going dark, and still present riders and drivers with one coherent global product? Following the framework from How to Answer a System Design Interview Question.

1. Requirements

Functional: identical to Design Uber's — match riders to nearby drivers, track live location, complete rides.

Non-functional, new at this scale:

• The system must keep operating in every unaffected region even if one entire region (a datacenter, a cloud provider's zone) goes down — the Disaster Recovery problem, applied to a live, latency-sensitive product rather than a batch-recoverable one.
• Cross-region latency must never sit on the ride-matching critical path — a rider in São Paulo can never be kept waiting on a round trip to a server in Frankfurt.
• Certain data is genuinely global (a driver's aggregate rating, a rider's payment method) and must be visible consistently no matter which region a person is currently using the app from.

Scale estimate: the matching workload itself is identical to the single-region version; what's new is running that same workload independently in perhaps 30+ regional deployments, plus a much smaller volume of cross-region account data that needs to replicate globally.

2. API Design

Functionally unchanged from Design Uber — the same POST /rides, location update, and nearby-driver endpoints. What's new is entirely in how a request gets routed before it ever reaches that API, covered in the deep dive below.

3. Data Model

The key modeling decision is what's regional versus what's global:

(regional, one full copy per region)
  drivers, rides, active-location-index  -- exactly Design Uber's schema

(global, replicated across all regions)
  driver_ratings   -- aggregate score, needs to be visible everywhere
  payment_methods  -- a rider's card, usable in any region they travel to

4. High-Level Design

System Design Lab

5. Deep Dive: regional isolation as the core strategy

The single most important design decision here is recognizing what Single Point of Failure analysis already implies: rides are inherently local — a São Paulo rider can never be matched to a Tokyo driver — so there is no correctness reason for regions to depend on each other at all for the actual matching workload. Each region runs a fully independent, self-contained deployment of the entire Design Uber architecture, and geo-DNS routes each user to their nearest region — exactly the layered "DNS picks a region, a regional load balancer picks a server" pattern already named as Disaster Recovery's standard shape. If South America's region goes down entirely, Asia's region is completely unaffected — riders and drivers there never notice, because nothing in their request path ever depended on South America's infrastructure being healthy.

This is the single biggest lesson this problem is built to test: resist the instinct to build one clever global coordination layer for a workload that doesn't actually need cross-region coordination at all. The right move is recognizing which data is genuinely regional (almost everything) and isolating it completely, rather than architecting for a global consistency problem that mostly doesn't exist.

6. Deep Dive: the genuinely global data, and its consistency model

The small slice of data that is global — ratings, payment methods, an account's existence — can't use the strong, single-leader-per-region model the regional data uses, because there's no one natural region that owns a traveling user's data. This is a direct, concrete instance of Strong vs. Eventual Consistency: a driver's rating updates asynchronously and propagates to every region within seconds via Data Replication, and a rider using the app in a country they don't usually live in might briefly see a slightly stale rating — an acceptable cost, since (unlike a driver being double-booked) a momentarily stale rating causes no real harm and resolves itself within moments.

System Design Lab

7. Tradeoffs

Full regional isolation is a deliberate simplification purchased at a real cost: some functionality (a rating, a payment method) genuinely needs to be global, and keeping that consistent across regions without undermining the isolation of everything else is exactly the harder problem worth being explicit about, rather than pretending the whole system can be regional with no exceptions.

Full isolation also has a sharper edge worth naming explicitly: it protects every region except the one currently in trouble. Geo-DNS reroutes new requests away from a failed region, but a ride already in progress there — a driver and rider mid-trip, matched and tracked entirely within that region's own stack — has no cross-region backup to fail over to, because nothing about that ride was ever replicated anywhere else. That ride is simply lost until the region recovers, which is an acceptable cost for the same reason the rest of this design accepts regional boundaries — replicating every in-flight ride's state globally, just to cover a rare regional outage mid-trip, would reintroduce the exact cross-region coordination cost this whole strategy exists to avoid, to protect against a failure mode that's rare and already bounded by the region's own redundancy within itself.

Full regional isolation vs. one global control plane: pros and cons

Pros

• ✓A regional outage never affects any other region's riders or drivers
• ✓Matching latency stays low — every request is served from the nearest region
• ✓Matches the workload's actual shape: rides are inherently local, so most data should be too

Cons

• ✕The genuinely global data (ratings, payment methods) still needs its own cross-region consistency story
• ✕Operating dozens of independent regional deployments is real ongoing operational overhead
• ✕A bug in the shared regional codebase can still affect every region simultaneously, even if infrastructure doesn't

Further Reading

• Uber Engineering — Multi-region architecture — Uber's own engineering writing on operating at global, multi-region scale.
• AWS Well-Architected Framework — Disaster Recovery — a refresher on the RPO/RTO framing this design's regional isolation strategy is built around.