Surge pricing - a price set by a map that changes every minute

Why this design

Surge pricing looks like a formula - demand over supply, times a constant - and the formula is the easy ten percent. The design question is about time and space: how big a piece of the city one price covers, how often it changes, how it is kept from oscillating when drivers and riders react to it, and how a price that changes every minute can still be a promise to the one rider who saw it. Every marketplace with dynamic pricing (rides, delivery, hotels, tickets) has the same skeleton.

What you will learn

• Why the city is cut into H3 hexagons, and what resolution 7 versus 8 versus 9 does to noise and fairness.
• Why the multiplier is recomputed on a 60-second clock from windowed counts rather than per request.
• Surge as a feedback controller: lag, overshoot, and the spatial and temporal smoothing that tame them.
• Why a shown price is a signed quote with an expiry, and what honouring it costs the platform.
• Guardrails that are not engineering at all: caps, emergency freezes and fairness rules, and why they belong in the pipeline rather than in a policy document.

How to read this board

1. Press Play. SIGNALS: drivers ping their location, riders open the app and ask for prices.
2. PER CELL, PER MINUTE: the aggregator counts both per hexagon, the surge computer turns ratios into multipliers, the guardrails smooth and cap them.
3. THE MAP is published, versioned, and pushed to drivers as a heatmap.
4. THE LOCKED PRICE, along the bottom right to left: a quote reads the map and locks the price, and the ride request honours it.
5. Then pages 1 to 6 and the DATA MODEL. Argue with the oscillation, the cell boundary and the quote the platform regrets.

Ask these before drawing anything

• What is surge FOR? Clearing the market (fewer riders, more drivers) is different from maximising revenue. This board optimises for completed trips and short pickup times; revenue is a consequence.
• How small is a "place"? Too large and a stadium is averaged into its quiet neighbourhood. Too small and a cell has two drivers and its ratio is noise.
• How fast must it react? A concert ending is an eight-minute event. A rainstorm is a two-hour one. A 60-second recompute covers both if the windows are chosen well.
• Is the price shown the price paid? For upfront pricing, yes - which forces a quote with an expiry.
• Are there legal caps? Many cities and states cap multipliers during declared emergencies. That is a hard requirement with a regulator behind it.
• Do drivers see the map? Showing it is how surge recruits supply; it is also how supply learns to game it.

Functional

• Maintain a multiplier per active H3 cell, recomputed every 60 seconds, between 1.0x and a per-market cap (for example 3.0x), in steps of 0.1.
• Quote: given origin, destination and product, return a fare including the multiplier, valid for 5 minutes, with an id.
• Request: accept a ride only with a valid, unexpired, unused quote, and charge exactly its fare (adjusted only for route changes the rider caused).
• Push a surge heatmap to drivers in the market.
• An operator can freeze or cap a market, or a polygon, instantly.

Non-functional

• Quote p99 under 100 ms: it is on the screen the rider is looking at.
• A published map is visible to every quote server within 5 seconds.
• Every multiplier ever published, and every quote, is reproducible for at least a year - regulators and disputes ask "why was I charged 2.4x at 23:12?"
• The pricing pipeline failing must fail to 1.0x, never to the last high value.

Out of scope

• Base fare computation (distance, time, tolls).
• Driver matching itself - see the ride-matching board.
• Driver pay, which is decoupled from rider price in upfront pricing.