Design surge pricing

Surge is only as good as its signals. Demand is not just booked rides: if prices are high, people stop booking, so bookings alone would make surge fall and then rise again. Use intent signals too: app opens and fare quotes in the cell (weighted lower than requests), and unfulfilled requests (a strong signal that supply is short). Supply is available drivers in the cell plus drivers whose current trip ends nearby in the next few minutes, because they will soon be free. Normalise both to the same window (say the last 5 minutes) and compute the ratio. Map ratio to multiplier with a configured curve: flat at 1.0 up to a threshold, then rising, then capped. The curve's shape is a business decision tuned by experiments using price elasticity (how conversion falls as multiplier rises) and how quickly drivers respond. More advanced systems predict demand 10-15 minutes ahead (time of day, weather, events, train arrivals) and price on the forecast, so drivers are already moving when the rush starts. In the interview, define demand and supply carefully and say that the formula is configurable and tested, rather than inventing a perfect equation.

A naive per-cell, per-minute ratio flickers: one cell is 2.1x, the next cell across the road is 1.0x, and a minute later they swap. Riders learn to walk 100 m or wait a minute; drivers chase cells that vanish. Three tools fix this. Spatial smoothing: compute each cell's value as a weighted blend of its own ratio and its neighbours' (H3 rings k=1, k=2), so prices change gradually across an area; very small cells also have too few events to be statistically reliable, and blending fixes that. Temporal smoothing: use an exponential moving average and limit the change per cycle (for example at most +0.3x or -0.2x per minute), with hysteresis so the price does not toggle around a threshold. Rounding: publish in steps of 0.1x or 0.25x. Hex cells help because all six neighbours are the same distance, unlike square geohash cells where diagonal neighbours are farther. Too much smoothing makes surge react slowly to a real rush, so tune the trade-off per city and measure both 'time to respond' and 'flicker rate'.

The rider must pay the price shown, even if the multiplier changes between the quote and the booking. Lock the multiplier into the quote: the quote service signs (HMAC) a token containing rider_id, pickup cell, vehicle type, multiplier, fare, snapshot version and expiry. When the rider books, the trip service verifies the signature and expiry, and uses the quoted fare. This needs no shared state on the booking path and works across any node. Make quotes single-use (mark quote_id used in Redis with SET NX) so one cheap quote cannot be reused for many rides. Within a single quote request, all vehicle types must use the same snapshot version; that is why the pricing job publishes a whole-city snapshot atomically rather than writing cells one by one. Expiry should be short (3-5 minutes): long enough to decide, short enough that a rider cannot hold a cheap price through a rush. If the user's pickup point moves significantly before booking, re-quote. Keep the snapshot version in the trip record, so support can answer 'why did I pay 1.6x' by looking at exactly what was in force.

Surge has real-world consequences, so controls are part of the design, not an afterthought. Caps: a per-city maximum and per-vehicle-type maximum in config, plus regulatory caps; in India, aggregator guidelines limit how far fares can go above the base fare, so the cap must be configurable per state. Emergencies: during floods, terror incidents or disasters, many companies cap or disable surge; the kill switch must work in seconds and must not depend on the pricing pipeline being healthy, so the lookup service checks a separate flag before using the snapshot. Overrides: operations can cap, floor or fix multipliers for a polygon and a time window (for example around a stadium after a match), with approval and an audit trail. Freshness guard: if the snapshot is older than a few minutes, decay to 1.0 rather than keep an old high multiplier forever. Fairness checks: run analyses to make sure surge does not systematically affect some neighbourhoods unfairly. Finally, test changes with experiments: switchback tests (alternate configs by time slot within a city) work better than user-level A/B tests, because riders and drivers in the same market affect each other.

A periodic SQL query over the last 5 minutes of events (in ClickHouse) is simpler to build and debug and is fine for one city. Flink keeps windowed counts incrementally and scales to hundreds of thousands of events per second with low lag. Use Flink at national scale; start with batch queries for a small launch.

Small cells (H3 res 9) target surge precisely but have noisy counts and create sharp borders. Large cells (res 7) are stable but blunt: a whole neighbourhood surges for one busy mall. Compute at a fine resolution and smooth over neighbours, or choose resolution by density (finer in city centres).

A multiplier hits long trips much harder than short ones. An additive surge (a fixed extra amount per trip) is easier to understand and fairer for long rides but may not attract drivers to short trips. Many apps now show only the final upfront fare and hide the mechanism; the back end can support both.

At 10x drivers, pings become millions per second, most of which do not change cell. Have the location service emit only 'driver entered/left cell' and status changes to the surge pipeline instead of raw pings; supply counts are then cheap to maintain.

Thousands of quote nodes loading a new snapshot every minute from Redis is a burst. Publish per-city snapshots as compressed blobs, notify via pub/sub, and let nodes fetch with jitter; or push via a CDN-like config distribution system.

Quote nodes keep using the last snapshot. After a maximum age (say 5 minutes), they decay multipliers toward 1.0 and alert. Pricing never blocks quoting.

Multipliers spike across a city. Guards in the pricing job compare the new snapshot to the previous one (for example, more than 30% of cells jumping by over 1x) and refuse to publish, keeping the last good snapshot. Configs are versioned so rollback is instant.

Signals arrive late, so surge lags reality. Alert on lag; the pricing job checks event-time freshness of its inputs and holds or decays multipliers if inputs are older than a threshold.