Surge pricing dynamics with delayed supply, oscillation and smoothing: an interactive simulator
When demand in an area outruns the drivers there, a ride-hailing marketplace raises the price. A higher price does two things: some riders decide to wait or go another way, and drivers nearby are drawn in. The second effect is delayed, drivers take minutes to arrive, and a feedback loop with a delay oscillates unless it is damped. That is why real surge systems smooth the signal, limit how fast the price moves and cap it.
The playground follows one city cell for an hour as a concert lets out. Compare a fixed price, a multiplier recomputed every minute, and a smoothed one.
Recomputing the price every minute jumps straight to 5×, pricing out 505 riders, while the drivers it attracts take 6 minutes to arrive. When they do, the queue is gone, the price crashes, drivers drift off, the queue builds, and the price spikes again: 13 price swings and 165 drivers arriving to find the surge over. It serves the most trips, 1,168, at the cost of prices nobody can predict.
What each policy does
- A fixed price lets the queue grow to 560 riders. Nothing brings extra drivers in, so 678 riders give up after waiting 8 minutes, and those served wait over 5 minutes on average.
- An instant multiplier clears the queue and serves the most trips, 1,168, but it jumps straight to 5× and swings 13 times as drivers arrive after the shortage has passed: 165 of them reach the cell to find the surge already over. Riders see prices change from one minute to the next, and drivers learn to chase surges that vanish.
- A smoothed, rate-limited, capped multiplier climbs to 2.5×, holds, and settles once: no swings, half as many drivers arriving too late, and 1,086 trips. It prices out a few more riders than the instant surge, but every rider who requests is served within minutes.
A sketch of the pipeline
every 30 to 60 s, per hexagon cell (H3 resolution 7 or so):
demand = ride requests and app opens in the last few minutes
supply = idle drivers in or near the cell, plus those about to finish a trip
raw = f(demand / supply) # a pricing curve, fitted from data
smooth = 0.5 * smooth + 0.5 * raw # an average over recent windows
price = clamp(prev + clamp(smooth - prev, ±0.5), 1.0, cap)
also smooth across neighbouring cells, so a street does not split two prices
the rider is quoted a price and it is locked for a few minutes;
drivers see a heat map of recent multipliers, not a promise of the futureAt scale this is a streaming job: location pings and requests are aggregated per cell in short windows, the multiplier is computed and smoothed, and the result is written to a fast store the pricing and matching services read. The quoted price is locked when the rider requests, so the price can change without surprising anyone mid-booking.
In a system design interview
For ride-hailing or delivery, describe the loop and its damping: “We aggregate requests and idle drivers per hexagon every 30 seconds in a stream processor and compute a multiplier from the ratio. We smooth it over time and across neighbouring cells, cap how fast it can change, and cap its height, because drivers react with a delay and an undamped price oscillates. The rider’s quote is locked for a few minutes.” Expect the follow-ups: how cells are sized, how to stop drivers gaming surge areas, and how to test a pricing change without hurting riders.
Read the guide to surge and dynamic pricing or dispatch and marketplace matching, see dispatch matching and autoscaling, which damps the same kind of loop, or watch a strong candidate design a ride-sharing app.
Questions people ask
How does surge pricing work?
The marketplace measures demand and available supply in small areas, such as hexagonal cells, every short interval, and raises the price multiplier where demand exceeds supply. Higher prices reduce requests from price-sensitive riders and attract drivers from nearby areas.
Why does surge pricing oscillate?
Because supply reacts with a delay: drivers drawn by a high price take minutes to arrive. If the price is recomputed instantly, it is still high while drivers are on their way, then crashes when they all arrive, and rises again once they leave. A delayed feedback loop without damping overshoots.
How do you stop surge prices from oscillating?
Smooth the demand and supply signal over several windows, limit how much the multiplier may change per interval, cap its maximum, and smooth across neighbouring cells. Locking the quoted price for a few minutes also shields riders from short-term movement.
How is surge pricing computed at scale?
Location pings and ride requests stream into a processing system that aggregates them per cell in short windows, computes and smooths the multiplier, and writes it to a low-latency store that pricing and matching services read on every request.
What cell size should surge pricing use?
Small enough that a multiplier reflects local conditions, but large enough to have meaningful counts. Hexagonal grids such as H3 are common because each cell has six equidistant neighbours, which makes smoothing across neighbours straightforward.
Why lock the price a rider is quoted?
So that the price does not change between seeing it and confirming. The multiplier can then update frequently without riders paying something they did not agree to, and the system honours the quote for a short window.
How are pricing changes tested?
With experiments that account for marketplace effects: changing prices for some riders shifts supply for everyone nearby, so tests often switch whole regions or time windows rather than individual users, and watch both rider and driver metrics.