Unit 5 — the metered meter, demand-based surge, and stable pricing
Fare Estimation & Pricing
The rider sees one number before they tap Confirm: the price. Get it right and they ride; get it wrong — quote 19 — and you lose them. That number is built directly on the distance and ETA from Units 1 and 4, then bent by the live balance of supply and demand.
This unit builds upfront pricing piece by piece — the metered meter, the surge multiplier that clears the market, the smoothing and hysteresis that keep it from flickering — and you implement each one, check it with python test.py, and unlock the next with a deterministic checkpoint.
Sub-unit 1 of 20
The problem: a reliable upfront fare
Quote a reliable upfront fare before the trip and keep pricing responsive to demand, without whiplash for riders or arbitrary swings.
Functional
- Estimate the fare from route distance and duration before the trip.
- Apply demand-based surge per pricing zone.
- Return a transparent breakdown: base, distance, time, surge, fees.
- Honor the quoted upfront price unless the route materially changes.
Non-functional
- Sub-millisecond fare computation on the request path.
- Surge that tracks demand without oscillating.
- Respect regulatory caps and transparency rules.
- An immutable audit trail for every quote.
Constraints
- Distance and ETA inputs are themselves estimates (Units 1, 4).
- Demand and supply shift minute to minute per zone.
- Surge events are noisy — most last under five minutes.
- Cached multipliers can go stale between refreshes.
Uber's own framing: surge pricing is a market-clearing mechanism. When requests outnumber drivers in an area, a higher price does two things at once — it rations scarce cars by pricing out some demand, and it pulls more drivers toward the shortage. The multiplier is the actuator of a supply/demand control loop, not an arbitrary markup.