New Year’s Eve at midnight. Thousands of people try to book rides simultaneously. Drivers are outnumbered 10 to 1. Without any intervention, every rider waits an hour. Surge pricing’s goal is to make more drivers available (higher fares attract drivers on the fence about working) and reduce demand (some riders opt for alternatives). The system design question is how you compute and apply it.

The Core Computation#

Surge is a function of the demand-to-supply ratio in a geographic zone.

surge_multiplier = f(pending_requests / available_drivers)

If ratio < 1.0: no surge, supply exceeds demand
If ratio 1.0-1.5: 1.2x surge
If ratio 1.5-2.0: 1.5x surge
If ratio > 2.0: 2.0x surge (often capped)

The exact function is tuned empirically. The goal is to attract enough drivers to clear the queue within N minutes. Surge too high and riders abandon the platform. Surge too low and the queue doesn’t clear.

Zone Management#

The city is divided into hexagonal zones (Uber uses H3, an open-source hexagonal grid system, similar in principle to geohashing but with uniform-area hexagons). Each zone has its own surge calculation.

Zone granularity is a trade-off: too fine, each zone has too few data points and surge fluctuates wildly. Too coarse, a zone with surplus drivers next to a zone with deficit doesn’t equilibrate. Typical zone sizes are roughly 1-5 km across.

graph TD A[Every 60 seconds per zone] --> B[Count pending_requests in zone] A --> C[Count available_drivers in zone] B --> D[Compute ratio: requests / drivers] C --> D D --> E[Look up surge multiplier from table] E --> F[Apply to ride quotes in zone] F --> G[Higher fares: attract drivers, deter some riders] G --> H[Zone ratio improves over next few minutes] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Smoothing and Lag#

Surge computed every second would oscillate wildly. A driver picks up a passenger: pending requests drop by 1, available drivers drop by 1, ratio jumps. Compute surge every second and it bounces between 1.2x and 2.0x every few seconds.

Smoothing: average the ratio over a rolling window (2-5 minutes). This adds lag but prevents thrash. Drivers see stable surge zones rather than flickering prices that make them question whether to reposition.

Preventing Abuse#

Without safeguards, surge creates arbitrage: a few people could flood the request queue with fake requests to trigger surge, then cancel after surge attracts drivers. Fraud detection on request cancellations (users who request and cancel repeatedly within surge zones) catches this pattern.

At Oracle#

We had a service capacity allocation system: different network slices competed for radio resources. When one slice had burst demand, it could request additional capacity. The allocation engine computed available capacity across all nodes every 30 seconds and distributed it proportionally. Same structure as surge pricing: measure supply and demand per zone, allocate dynamically, smooth to prevent oscillation. The 30-second refresh window was a tuned trade-off between responsiveness and stability.

What I’m Learning#

Surge pricing is a feedback control system: measure supply/demand imbalance, apply a price signal, observe the response, iterate. The engineering is in the zone granularity, the smoothing window, and the mapping from ratio to multiplier, all of which require real-world data to tune.

Have you built systems with feedback loops that adjusted behavior based on real-time load measurements?