How Uber works

Loading the interactive diagram…

Uber, as text

Live driver locations, matching through a geospatial index, and surge pricing.

Clients

Rider app: Client · Hypothetical. Requests rides, shows the driver on the map, and pays.
Driver app: Client · Hypothetical. Goes online, sends GPS pings and accepts trip offers.

Edge

API gateway: Gateway · Hypothetical. Authenticates rider requests and routes them to the right service.
WebSocket gateway: Gateway · Hypothetical. Holds a live connection to every online driver app for pings and offers.

Core services

Trip service: Service · Hypothetical. Owns each trip from request to payment.
Dispatch: Service · Assumption. Matches each ride request to a nearby available driver.
Location service: Service · Assumption. Ingests driver GPS pings and keeps each position current.
Pricing and surge: Service · Hypothetical. Quotes fares and applies surge multipliers per area.
Payments: Service · Hypothetical. Charges the rider and pays the driver when a trip ends.
Notifications: Service · Assumption. Sends trip offers to drivers, plus updates and receipts.

Data and events

Kafka event bus: Queue · Hypothetical. Carries trip and location events between services.
Trip and user stores: Database · Hypothetical. Durable records of trips, riders and drivers.
Geospatial index: Database · Documented. Stores driver positions by H3 hexagon cell.

Flow: Ride request and matching

From tapping Request to seeing a driver on the map: the request goes in, answers come back, and the driver is found and told.

Rider app → API gateway (Request ride). The rider taps Request. The app sends the pickup and drop-off to the API gateway.
API gateway → Trip service (Create trip). The gateway checks who the rider is and passes the request to the trip service, which creates a new trip.
Trip service → Pricing and surge (Price this trip). The trip service asks pricing what this ride should cost right now.
Pricing and surge → Trip service (Fare + surge). Pricing answers with the fare, including any surge multiplier for the area.
Trip service → API gateway (Trip created). The trip service replies to the gateway: the trip exists and has a fare.
API gateway → Rider app (Finding driver…). The rider's app shows the fare and a "Finding your driver" screen. The rider is now waiting.
Trip service → Dispatch (Find a driver). Meanwhile, the trip service asks dispatch to find a driver for this trip.
Dispatch → Geospatial index (Who's nearby?). Dispatch asks the geospatial index for available drivers in the hex cells around the pickup point.
Geospatial index → Dispatch (Nearby drivers). The index answers with nearby drivers. Dispatch ranks them by how soon each could arrive.
Dispatch → Notifications (Offer to best). Dispatch picks the best driver and asks notifications to send them the trip offer.
Notifications → WebSocket gateway (Trip offer). Notifications hands the offer to the WebSocket gateway, which holds an open connection to every online driver.
WebSocket gateway → Driver app (Trip offer). The offer is pushed down that open connection. The driver's phone rings with the new trip.
Driver app → WebSocket gateway (Accept). The driver taps Accept. The answer travels back over the same connection.
WebSocket gateway → Trip service (Driver accepted). The gateway tells the trip service, which marks the trip as matched.
Trip service → API gateway (Driver matched). The trip service sends the news back towards the rider.
API gateway → Rider app (Driver on the way). The rider's app shows the driver, the car and the arrival time. The round trip is complete.

Flow: Driver location updates

How a GPS ping from a driver's phone becomes searchable. Pings are fire-and-forget: nothing is sent back, so this flow only goes one way.

Driver app → WebSocket gateway (GPS ping). Every few seconds the driver app sends its position over its open WebSocket connection.
WebSocket gateway → Location service (GPS ping). The gateway forwards the ping to the location service.
Location service → Geospatial index (Update cell). The location service works out which H3 hexagon the driver is in and updates the geospatial index.
Location service → Kafka event bus (Driver moved). It also publishes the movement as an event, so other services can react without asking.

Flow: Surge pricing

How demand and supply in an area change the price. This runs in the background, so nobody waits for a reply.

Trip service → Kafka event bus (Ride requested). Each ride request is published as an event. Together they show demand in each area.
Location service → Kafka event bus (Driver moved). Driver movements are published too. Together they show supply.
Kafka event bus → Pricing and surge (Demand vs supply). Pricing reads both streams, compares demand and supply per area, and raises the multiplier where riders outnumber drivers. The next fare quote uses it.

Flow: Trip completion and payment

What happens when the driver ends the trip, until both sides see the result.

Driver app → WebSocket gateway (End trip). The driver taps End trip. The event travels over the WebSocket gateway.
WebSocket gateway → Trip service (End trip). The trip service marks the trip as completed and works out the final fare.
Trip service → Payments (Charge rider). The trip service asks payments to charge the rider.
Payments → Trip and user stores (Save charge). Payments records the charge and the driver's earnings durably.
Trip and user stores → Payments (Saved). The store confirms the record is safe.
Payments → Notifications (Send receipt). Only after the charge is stored does payments ask notifications to send the rider's receipt.
Payments → Trip service (Paid). Payments tells the trip service the charge went through.
Trip service → WebSocket gateway (Trip closed). The trip service confirms back to the driver's connection.
WebSocket gateway → Driver app (Earnings). The driver's app shows the fare earned. Both sides are done.

Sources

HowItScales is not affiliated with the companies shown. Components marked Assumption or Hypothetical are not confirmed by the company.