Surge pricing reacts to imbalance. Driver repositioning tries to prevent it. If the system knows which zones will be in high demand in the next 30 minutes, it can suggest that idle drivers reposition there before the surge starts. That prediction is the hard part.

Demand Forecasting Per Zone#

Historical patterns are strong for predictable events: the airport zone is high demand every Friday evening. The downtown zone surges at bar close time on weekends. Train stations spike when large trains arrive.

For each zone, at each hour-of-day and day-of-week combination, historical demand data gives an expected request rate. A zone with normally 10 requests per hour that suddenly has 50 pending requests is probably experiencing an unplanned event (a concert just ended, a sports game let out). The system sees the demand spike in real time and can respond.

For planned events (concerts, sports games), the platform can ingest event schedules and pre-position drivers nearby before the event ends.

Repositioning Suggestions#

The app shows drivers a heat map of demand zones. High-demand zones glow bright on the map. No algorithm forces drivers to reposition; it shows them where the money is and lets them decide.

More sophisticated: the system calculates expected earnings per hour for a driver in each nearby zone given current supply and demand. It shows drivers “go to downtown zone: estimated 3.2 trips per hour at current rates.” This is more actionable than a heat map.

graph TD A[Zone demand data: real-time + historical] --> B[Demand Forecasting Model] B --> C[Predicted high-demand zones for next 30min] C --> D[Driver is idle, nearby] D --> E[App shows: high demand at downtown zone, 2km away] E --> F[Driver chooses to reposition] F --> G[Supply improves before demand peaks] 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

The Aggregation Pipeline#

Zone demand metrics are computed continuously. Every few seconds, the system counts active requests and available drivers per zone. This is a streaming aggregation: events (ride requests, driver check-ins, ride completions) flow into a stream processor that maintains running counts per zone.

At millions of events per second across thousands of zones, this is a substantial stream processing workload. Approximate counts using Count-Min Sketch are accurate enough for surge decisions while being computationally cheap.

Boundaries Between Zones#

Zone boundaries create discontinuities. A driver at the edge of Zone A and Zone B sees different demand signals depending on which zone they’re technically in. If Zone A has 2.0x surge and Zone B has 1.0x surge with the boundary between them, the driver’s app might flicker between surge and no-surge as GPS updates place them in different zones.

Smoothing at zone boundaries: the demand signal for a driver is a weighted average of the demand in nearby zones, weighted by distance, not a hard switch at the zone boundary.

At Oracle#

We had geographic regions for our 5G network that had different traffic profiles. Backhaul capacity allocation was per region. A sporting event in one city’s region would spike traffic and require temporary capacity reallocation from neighboring regions. We built a rule-based system: if region X exceeds 80% capacity, borrow from region Y. This was manual rules, not ML. It worked well enough for predictable events but missed unexpected spikes. The lesson: for unpredictable events, you need real-time sensing, not just rules.

What I’m Learning#

Supply-demand balancing at geographic scale requires both reactive (surge pricing) and proactive (repositioning suggestions) mechanisms. The proactive side is more valuable but requires demand forecasting, which needs historical data and real-time sensing working together.

Have you built systems where proactively positioning resources prevented bottlenecks better than reactive scaling alone?