Problem Statement: Ride-Demand Hotspot Analysis
Why demand hotspots are a spatiotemporal aggregation + forecast + repositioning problem.
Problem Statement: Ride-Demand Hotspot Analysis
A ride-demand hotspot system predicts where and when riders will want cars, and uses that to guide idle drivers toward the demand before it peaks. When a concert lets out downtown, demand spikes in a few blocks for ten minutes; if drivers are scattered across the city, riders wait and surge spikes. This system aggregates live demand signals into a spatial heatmap, forecasts the next few minutes per area, and tells idle drivers where to go — Uber's and DiDi's repositioning guidance. It splits into three problems.
First, spatiotemporal aggregation. Ride requests, app opens, and searches are events with a location and a time. We bucket them into spatial cells (H3 hexagons or geohash) over sliding time windows — counting demand per cell per minute, continuously, at high volume. This is a streaming aggregation, not a batch report.
Second, short-horizon forecasting. Current demand is not enough; drivers need to be where demand will be in 5-15 minutes (the time to drive there). We forecast per-cell demand for the near horizon from recent windows (decay-weighted recent demand plus daily/weekly seasonality), refreshed every minute. This is light, streaming, per-cell forecasting — not a heavy nightly model.
Third, supply-demand imbalance + repositioning. We compare predicted demand against available supply (idle drivers) per cell to find under-served cells, then recommend idle drivers reposition toward them. The crux is avoiding over-herding — if we send every idle driver to one hot cell, it floods, demand is over-met, and neighbors starve. The guidance must close the gap, not overshoot.
Note what this is not: it is not surge pricing. It is the prediction and guidance layer — the heatmap and repositioning that feed pricing and matching, not the pricing engine itself.
The scale is a major platform: ~25M trips/day, with demand-signal events (requests, app opens, driver GPS) at hundreds of thousands per second at peak, aggregated into H3 cells (~0.7 km² each) over 1-minute windows, forecasting a 5-15 minute horizon for hundreds of thousands of idle drivers. The hard parts are high-volume streaming aggregation, a responsive-yet-stable forecast, and repositioning that doesn't over-herd — a streaming-analytics-and-control problem wearing a maps costume.
Key Highlights
- •Predict WHERE/WHEN riders will want cars and guide idle drivers there before demand peaks (repositioning guidance) — Uber/DiDi style
- •Spatiotemporal aggregation: bucket request/app-open events into H3/geohash cells over sliding time windows (streaming, high-volume), not batch
- •Short-horizon forecast (5-15 min, refreshed every ~1 min) from decay-weighted recent demand + seasonality; light streaming, not a nightly model
- •Supply-demand gap → reposition idle drivers to under-served cells WITHOUT over-herding; NOT surge pricing — this is the prediction/guidance layer feeding pricing
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will frame this as streaming spatiotemporal aggregation + short-horizon forecast + repositioning guidance."
- "This is the prediction/guidance layer, not the surge-pricing engine."