Low Level Design: Supply-Demand Balancing Service

What Is a Supply-Demand Balancing Service?

A supply-demand balancing service continuously monitors the ratio of available drivers (supply) to outstanding ride requests (demand) across geographic zones. Its job is to detect imbalances early and trigger corrective actions such as driver incentives, demand-side price adjustments, or repositioning nudges. Without it, localized driver shortages or surpluses go undetected until riders experience long waits or drivers sit idle.

Data Model

The system operates on zone-level aggregates rather than individual driver records. Zones are defined using an H3 hexagonal grid at resolution 7 (average area ~5 km²).

-- Zone snapshot (written every 30 seconds)
CREATE TABLE zone_snapshots (
  zone_id       VARCHAR(20),   -- H3 hex cell ID
  snapshot_time TIMESTAMP,
  available_drivers  INT,
  active_requests    INT,
  avg_wait_sec       INT,
  supply_ratio       DECIMAL(5,2),  -- drivers / requests
  PRIMARY KEY (zone_id, snapshot_time)
);

-- Driver incentive campaigns
CREATE TABLE incentive_campaigns (
  campaign_id   UUID PRIMARY KEY,
  zone_id       VARCHAR(20),
  bonus_amount  DECIMAL(6,2),
  valid_until   TIMESTAMP,
  status        VARCHAR(20)    -- 'active', 'expired', 'cancelled'
);

Real-time counters are maintained in Redis for sub-second reads:

-- Increment on driver availability change
INCR zone:supply:<zone_id>
DECR zone:supply:<zone_id>

-- Increment on new ride request
INCR zone:demand:<zone_id>

-- Read current ratio
GET zone:supply:<zone_id>
GET zone:demand:<zone_id>

Core Algorithm: Demand Forecasting and Rebalancing

The balancing service runs two loops at different cadences:

Short-Term Loop (every 30 seconds)

Read supply and demand counters for all active zones from Redis.
Compute supply ratio: ratio = available_drivers / max(active_requests, 1).
Flag zones where ratio falls below threshold (e.g., <0.8) as undersupplied.
Flag zones where ratio exceeds threshold (e.g., >3.0) as oversupplied.
Persist snapshot to zone_snapshots for trend analysis.

Forecasting Loop (every 5 minutes)

Pull 4-week historical snapshots for each zone, same day-of-week and hour window.
Apply a simple exponential smoothing model to predict demand 30 minutes ahead.
Pre-emptively trigger incentives in zones forecasted to go undersupplied before the imbalance becomes acute.

Corrective Actions

Driver nudges: Push a notification to nearby offline drivers highlighting high-demand zones with a bonus offer.
Repositioning suggestions: Show in-app heat maps to available drivers, suggesting movement toward undersupplied zones.
Demand throttling: Signal the surge pricing service to increase price multipliers in undersupplied zones, dampening inbound request rate.

Failure Handling

Stale counters: Redis counters are reconciled against database counts every 5 minutes. Any drift beyond 10% triggers a full counter reset from the source of truth.
Forecast model failure: If the forecasting job fails, the system falls back to reactive-only mode using the short-term loop. An alert fires for on-call engineers.
Incentive over-triggering: A rate limiter caps incentive campaigns per zone at 1 active campaign per 15-minute window to prevent runaway bonus payouts.

Scalability Considerations

Zone granularity tuning: In dense urban areas, use H3 resolution 8 (smaller cells) for finer-grained detection. In rural areas, resolution 6 reduces the number of zones to monitor.
Event-driven updates: Rather than polling, driver status changes and new ride requests publish events to a Kafka topic. The balancing service consumes these to maintain counters in near real-time.
Read scalability: Zone snapshot queries for dashboards and analytics are served from a read replica or a columnar store (e.g., ClickHouse) to avoid contention on the operational database.

Summary

The supply-demand balancing service is the feedback control loop of a ride-sharing platform. By combining real-time Redis counters with historical demand forecasting, it enables proactive interventions before shortages become rider-visible. The key design decisions are zone granularity, forecasting horizon, and the rate-limiting of corrective actions to avoid oscillation between over- and under-correction.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is supply-demand balancing in the context of marketplace system design?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Supply-demand balancing is the process of dynamically aligning available supply (e.g., drivers, hosts, inventory) with incoming demand (e.g., ride requests, bookings) in real time. It involves forecasting demand using historical data and ML models, incentivizing supply to reposition or stay active, and using pricing signals to modulate demand when supply is constrained.”
}
},
{
“@type”: “Question”,
“name”: “How do you forecast demand for a supply-demand balancing system?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Demand forecasting typically uses time-series models (e.g., ARIMA, Prophet) combined with features like time of day, day of week, weather, local events, and historical request density per geohash cell. Predictions are served via a low-latency feature store and updated on a rolling basis. Short-horizon forecasts (next 15-30 minutes) drive real-time dispatch decisions, while longer-horizon forecasts guide driver incentive programs.”
}
},
{
“@type”: “Question”,
“name”: “What data stores are best suited for a supply-demand balancing service?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Real-time supply state (driver locations, availability) is best stored in Redis with geospatial indexing. Demand signals and aggregated metrics flow through a stream processing layer like Kafka Streams or Flink. Historical data for forecasting lives in a columnar data warehouse (e.g., BigQuery, Redshift). A time-series database such as InfluxDB or Prometheus is useful for monitoring supply-demand ratio metrics per zone.”
}
},
{
“@type”: “Question”,
“name”: “How do you prevent supply-demand imbalances from cascading across regions?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Regional isolation is key: each geographic zone maintains its own supply-demand state and balancing logic, preventing a surge in one area from starving resources in another. Cross-zone rebalancing uses controlled incentive spill-over with rate limits. Global circuit breakers detect runaway incentive spend and throttle payouts. Real-time dashboards with automated alerting allow on-call engineers to intervene before imbalances compound.”
}
}
]
}