Bifalgorithm post

Let's design Uber. It sounds simple. A rider opens the app, enters a destination, requests a ride, a driver shows up. But behind that one button sit several hard distributed systems problems at once. First, location. Drivers are constantly moving, so the back end takes frequent GPS updates from millions of phones. You can't query a normal relational database every time someone asks, which drivers are near me? Way too slow. So driver locations live in a store optimized for geospatial queries. Find all available drivers within 3 kilometers of this rider. The rider taps request ride. The back end creates a trip request, and the matching system looks at nearby drivers. But we don't notify every driver in the city. We rank them by distance, estimated arrival, availability, vehicle type, and sometimes marketplace conditions. Then the trip gets offered out. Here's where concurrency matters. Two drivers accept at almost exactly the same moment. Only one can get it. So the back end needs an atomic update that moves the trip from waiting to assigned. First successful ride wins. Everyone else is rejected. Now the driver heads toward the rider. Both phones keep streaming location, and those updates have to reach the back end fast, so the rider sees the car moving on the map. But you don't want every GPS coordinate permanently in your main database. That's an enormous amount of data. So recent location lives in fast temporary storage, while important trip events go to durable storage. Then ETA. Uber estimates how long until the driver reaches you and how long the whole trip takes. That needs road network data, traffic, historical travel times, and the current positions of both driver and rider, and it keeps changing during the trip. Then pricing. A pricing service calculates fare from distance, estimated duration, vehicle type, location, and current demand. Hundreds of riders, only a few drivers available. Prices may rise to balance supply and demand. Now imagine something fails. Payments goes down. The entire trip system shouldn't crash, because one service is unavailable. So the architecture splits into many services. Trip, driver, location, pricing, payment, notification. Each scales and fails independently, and they communicate through events and queues. Trip accepted. Driver arrived. Trip started. Trip completed. Those events trigger payments, notifications, receipts, and analytics without forcing everything into one giant request. Now think about scale. Friday night, millions of riders, millions of drivers moving, location updates every few seconds, constant trip requests. You can't run that from one data center, so the system is distributed geographically, routing users to infrastructure close to them. Simplified, Uber is a real-time marketplace. One side publishes supply, available drivers. The other creates demand, riders requesting trips. The back end matches them quickly while continuously updating location, price, ETA, and trip state. The hard part isn't putting a car icon on a map. It's making millions of moving devices agree on what's happening in real time.

Let's design Uber. It sounds simple. A rider opens the app, enters a destination, requests a ride, a driver shows up. But behind that one button sit several ha…