Ride Sharing

A ride-sharing backend looks deceptively simple — a rider taps a button, the system finds a nearby car, a trip begins. The hard part hides in the asymmetry of the workload. For every rider request, the drivers around them emit a relentless stream of GPS pings, so the system is dominated not by reads of trips but by a firehose of location writes. On top of that, a match must be fast (a rider is staring at a spinner), geographically scoped (you want the car two blocks away, not across the city), and resilient (a network partition or a dead matcher during rush hour must not stall the whole city). This guide builds the matching backend the way you would in a FAANG interview: clarify what is actually being asked, size the firehose with real numbers, then assemble a region-partitioned architecture with an in-memory geo index, a queue that absorbs the pings, and redundant matcher paths that survive failure. We anchor every decision to a concrete target. The reference design we converge on is a regional load balancer fronting two independent matcher pools, a location-ingest queue, an in-memory geo index, and a durable trips store — tuned to hold a 96 percent match-success rate, a sub-120ms p99, and a throughput floor of at least 15,000 served requests per second as load doubles to 30,000 at rush hour, all while a region partitions, a matcher dies, and the trips store blips. Those are the exact SLOs the SysGym simulator grades you against, so the article and the gym reinforce each other.