Surge and dynamic pricing systems

How marketplaces adjust prices in real time: measuring supply and demand per area, computing multipliers in a stream, smoothing and caps, price quotes and locking, fairness and regulation, and experimenting with pricing.

Reading is half of it. See this used in a real interview: walk through Design Uber →

When rain starts at rush hour, ride requests double while the number of drivers stays the same. Without a price signal, wait times explode and most riders get no car. Surge pricing raises prices in that area to reduce marginal demand and attract drivers from nearby. Delivery fees, hotel and flight pricing and ticket sales use similar dynamic pricing. In interviews, it is a natural extension of ride-sharing and delivery designs, and it tests streaming aggregation and careful consistency around quotes.

Measuring supply and demand

Divide the city into cells (for example hexagons with H3). For each cell, over a short sliding window (one to five minutes):

• Demand: ride requests, app opens with a destination entered, and unfulfilled requests.
• Supply: available drivers in or near the cell, including those about to finish trips there.
• Outcomes: current pickup ETAs and match rates.

These come from location updates and request events, aggregated by a stream processor. See batch and stream processing and geospatial and proximity.

Computing the multiplier

A simple version maps the demand-to-supply ratio (or predicted ETA) to a multiplier through a curve: below a threshold, 1.0; above it, rising gradually, capped at a maximum. More advanced versions use models predicting demand in the next minutes and choose prices that balance wait times and completion rates.

Make it stable:

• Smoothing over time and across neighbouring cells, so prices do not flicker or jump at a cell boundary.
• Hysteresis: require sustained imbalance before rising or falling.
• Caps, and often lower caps or none at all during emergencies, by policy or law.

Serving prices

Multipliers per cell are recomputed every minute or so and published to a fast key-value store or in-memory cache that the pricing service reads. A price request combines the base fare (distance, time from the routing ETA, product type), the multiplier for the pickup cell, fees and promotions.

Quotes and locking

The rider sees a price, then requests a ride a few seconds later; the surge may have changed in between. Issue a quote:

• The pricing service returns a price with a quote id and expiry (for example two minutes), stored or signed so it cannot be tampered with. See hashing and encoding.
• The ride request includes the quote id; if still valid, that price is honoured.
• Expired quotes require a new quote, shown to the user.

This keeps prices consistent from the user's view without global locking. The same pattern holds for hotel rates and flight fares (a quote held during checkout). See Design Airbnb.

Driver side

Surge also guides supply: heat maps show drivers where prices are high, and incentives ("earn extra for trips from the airport") move supply before demand peaks. Show drivers the same smoothed data riders see to avoid drivers chasing short-lived spikes.

Other dynamic pricing

• Delivery fees: higher when couriers are scarce or distances long; small order fees. See Design DoorDash.
• Hotels and rentals: prices by season, day of week, occupancy and lead time, usually computed in batch with daily adjustments.
• Tickets: dynamic pricing for high-demand events, plus queues to control the rush. See Design Ticketmaster.

Fairness, trust and law

• Users dislike surprises: show the multiplier or final price clearly before confirming.
• Avoid pricing on personal attributes; many places regulate price discrimination and surge during emergencies.
• Log every price and its inputs for audits and disputes.

Experiments

Pricing changes affect both sides of the market in an area, so standard user-level A/B tests are biased. Use switchback experiments (alternate the whole city between policies by time window) or region-level tests. See feature flags and A/B testing.

In the interview

For Design Uber: stream aggregation of requests and driver locations per H3 cell, a smoothed and capped multiplier recomputed each minute, served from cache, signed quotes with expiry honoured at request time, and switchback experiments to tune the curve.

Checklist

• Supply and demand per cell over sliding windows.
• Multiplier curve with smoothing, hysteresis and caps.
• Fast serving from a cache refreshed every minute.
• Signed, expiring quotes honoured at booking.
• Clear display, auditing of prices and inputs, legal constraints.
• Switchback or regional experiments.