A ride-hailing platform in the mould of Grab operates in eight cities across four countries. Matching a rider to a driver needs the live positions of nearby drivers and must answer in under 500 ms. Payments, identity and analytics are central. Where should the matching engine run?
Show the full answer Hide the answer
The deciding property
Matching is a read-heavy query over a small, intensely mutable, geographically local dataset. Every driver in a city writes a position every few seconds, and a match needs a consistent-enough view of the drivers within a few kilometres. That makes write locality, not user proximity, the property that settles placement: the compute must sit where the writes land, because moving the matching decision away from the position store means paying a round trip per query against data that changes faster than you can cache it.
A city's drivers and riders are in the same place by definition. Put the engine in the nearest region, keep the position store in the same region, and the latency budget is spent on the algorithm rather than the network.
Why one region per country
Country granularity usually wins over city granularity because the data that makes matching legal and priced correctly is national: driver licensing, fare rules, tax, and increasingly a data-residency requirement that says position data about local citizens stays in the country. One region per country lines the technical boundary up with the regulatory one, and a failure is confined to one market's dispatch rather than the region's.
Why not the others
- Edge functions everywhere. The edge is the wrong tier for state that changes every few seconds: each PoP would need the city's positions, which means replicating a high-write dataset to dozens of places to serve queries that only care about one. You would add consistency problems to a problem that had none, and the latency you save is a handful of milliseconds against a 500 ms budget.
- Single global region with read replicas. Replicas serve reads with lag, and a stale driver position produces a match to a driver who has moved or already accepted a ride. The failure is silent and it corrupts the marketplace rather than erroring.
- On-device peer discovery. Devices cannot see each other's networks, cannot be trusted with fare or fraud logic, and cannot make a global decision about supply. It also puts the matching rules where a user can read them.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| One city grows past what a single write path can absorb | A cell per city inside the country region | The position store, not the engine, becomes the constraint |
| Markets merge into one regulatory zone with no residency rule | One region per continent | Fewer footprints to operate, same latency class |
| The product becomes scheduled rather than on-demand | Central region | Nothing is latency-critical once matching runs minutes ahead |
| Cross-border trips become common | A routing layer above per-country engines | The match itself still needs local data |
When this is over-engineering
A single-city operation should run in one region and stop. Multi-region dispatch costs you a replication story, an operational rota per footprint, and a per-market deployment pipeline. The threshold is the second country or the first residency rule, whichever arrives first.