System Design

Surge Pricing

Design dynamic surge pricing for a ride-hailing or delivery app like Uber or DoorDash.

Functional requirements

• Driver apps report location and availability every few seconds; rider apps report ride requests and price checks with a pickup location.
• For any pickup location the system computes a surge multiplier (e.g., 1.0x to 3.0x) from the balance of open requests and idle drivers nearby over the last few minutes.
• A rider asking for a fare gets a quoted price that is honored for a short window (e.g., 2 minutes) if they book, even if the multiplier changes in between.
• Drivers see a live heat map of surging areas so they can move toward demand, and riders see the current multiplier before requesting.
• Operations staff can cap the multiplier per city, freeze surge during a declared emergency, and review how the multiplier evolved for any cell.

Non-functional requirements

• The loop is fast: a supply or demand change in a cell reaches the multiplier riders and drivers see within 10 seconds; p99 for a price quote is 150ms.
• Quotes are strongly consistent with what is charged: a booked ride pays its quoted multiplier for the whole window, never a newer one, and riders quoted in the same cell at the same second see the same value.
• Availability over freshness for the multiplier: if the pipeline stalls, apps keep the last known value with a bounded age (decaying to 1.0x after 5 minutes stale), not an error.
• Every quote is durable for the life of the trip and every multiplier decision is kept with its inputs; fares are disputed and regulators audit surge.
• The multiplier is smooth and hard to game: no jump from 1.0x to 3.0x in one tick, and a few drivers going offline or one device spamming price checks cannot move it.

Scaling & constraints

• 5M active drivers reporting location every 4 seconds: ~1.25M location updates per second at global peak, ~300 bytes each.
• 30M ride requests per day plus ~10x as many price checks: ~3,500 requests/sec and ~35,000 price checks/sec at peak, spiking 5x in one city when a stadium empties or a subway line fails.
• Cities are divided into ~2M cells (H3 resolution 8 or geohash 6, roughly 0.7 sq km each) across 10,000 cities; the multiplier uses a sliding window of the last 2 to 5 minutes.
• Read:write ratio for the multiplier is about 30:1: every price check and heat map refresh reads it, and a driver app refreshes the heat map every 15 seconds.
• A quote is ~1 KB, lives 2 minutes, and must be looked up at booking; ~10% of quotes convert to a booked ride, matching the 10:1 price-check to request ratio.
• Multiplier history is retained for 1 year for audit; driver and rider populations grow ~25% per year.

Out of scope

• Driver-rider matching and dispatch.
• The pricing model's economics: how a supply and demand ratio maps to a multiplier.
• Base fare calculation, route pricing, tolls, and tipping.
• Payment processing and driver payouts.