STANDARDwalkthrough

Surge Pricing

5 of 8

3 related

It is New Year's Eve at midnight. Demand for rides in Times Square spikes 10x while half the drivers go offline.

The constraint: naive surge causes oscillation: surge goes up, riders stop requesting, surge drops, riders flood back, surge spikes again. We chose per-cell surge with EMA smoothing (not global surge, not instantaneous per-cell) because per-cell isolates geographic demand while EMA dampens the oscillation cycle.

“Without surge pricing, riders wait 30+ minutes and most give up.”

Trade-off: we accepted a 2-3 minute delay in surge response in exchange for stable pricing. The formula: compute ride requests per H3 cell over the last 5 minutes, divide by available drivers in that cell.

If the ratio exceeds 2:1, apply a multiplier:

\text{surge} = \min(\text{ratio} \times 0.5, 5.0)

. A 4:1 demand-to-supply ratio means a 2.0x surge.

We smooth with an Exponential Moving Average:

\text{EMA}_t = \alpha \times \text{ratio}_t + (1 - \alpha) \times \text{EMA}_{t-1}

with

\alpha = 0.3

. This dampens oscillation while still responding to genuine demand shifts.

Surge computation runs as a batch job every 60 seconds per cell. At 500K H3 cells covering active cities, that is 500K computations per minute.

Why it matters in interviews

Interviewers expect us to explain surge per geo cell, not globally. What if the interviewer asks: 'Why not compute surge on every request instead of batching every 60 seconds?' We answer: per-request computation at 35 requests/sec peak would see micro-fluctuations in a single cell. The 60-second batch window averages out noise and the EMA further smooths it.

Related concepts

← PreviousQuadTree vs H3 Grid Next →ETA Estimation