Design dynamic and surge pricing for a marketplace

In this article

1. Before you start
2. Why interviewers ask this
3. Dynamic and surge pricing from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one worked problem in the machine learning (ML) system design guide.

Why interviewers ask this

Pricing looks like a forecasting problem, so it shows whether a candidate sees the marketplace behind the model. A price change moves demand, supply and wait times together, and a price that raises revenue in one hour can hurt it later. The question also tests causal thinking: the data you have was generated by the old pricing rule.

A weak answer trains a model to predict demand and multiplies the price by the forecast. A strong answer defines the objective and its limits, estimates how riders respond to price from experiments, not from raw history, and tests with a design that survives shared supply. It adds a cap and an explanation for fairness. The prompt appears in system design rounds for ride-hailing, delivery and travel roles, as "design surge pricing" or "build a dynamic pricing model".

Dynamic and surge pricing from first principles

Surge multiplier

A surge multiplier is a number that multiplies the standard fare in a small area and time window when demand outruns supply, so that the higher price both reduces requests and draws more drivers.

Price elasticity of demand

Price elasticity of demand is the percentage change in the quantity people want for a one percent change in price, so an elasticity of 1.5 means a 10% price rise cuts demand by about 15%.

Switchback experiment

A switchback experiment is a test that randomly switches a whole market between the control price and the new price over successive time blocks, and compares the blocks, so everyone in a block shares one price.

In plain words

Imagine a stall selling cold drinks on a hot day. When a crowd arrives and stock runs low, the seller raises the price a little. Some people walk away. The drinks go to those who value them most. A helper may rush to bring more crates. Surge pricing is that move at scale: a higher price rations scarce rides and attracts supply. The analogy breaks here: a stall sells to a crowd in sight, but a platform sets thousands of prices at once and must prove that the change helped.

In one precise sentence: a pricing system forecasts each area's supply and demand, estimates how both respond to price, sets a bounded multiplier that clears the market and measures it with an experiment that respects shared supply.

Step 1: Define the objective and the guardrails

The input is the business goal; the output is an objective and its limits. A pricing system trades at least four things: completed trips, wait time, revenue and fairness. Pick one primary objective, such as completed trips with a wait under a target. A guardrail metric is a measure that must not get worse, such as completion rate, wait time or cancellations.

Hall, Kendrick and Nosko describe the mechanism: when there are relatively more riders than driver-partners, an algorithm assigns a simple multiplier to the standard fare, and the rider must acknowledge the higher price before a request is sent (Hall et al., 2015). Their case study frames success as a stable wait: in the concert example, the average wait was 2.6 minutes and the completion rate did not change despite a demand spike. What you now know: the objective and guardrails come before the model.

Step 2: Estimate elasticity from experiments, not from history

Elasticity cannot be read from history, because the old rule raised prices when demand was high. A fit on history mixes demand driving the price with the price driving demand, and can even show higher prices alongside more riders. You need variation in price that is unrelated to demand. Cohen and colleagues used a regression discontinuity design on almost 50 million individual-level observations, exploiting the surge algorithm to estimate demand elasticities at several points along the demand curve (Cohen et al., 2016).

A regression discontinuity compares riders just below and just above a threshold at which the price jumps, since those riders are otherwise alike. You can also create variation on purpose with small randomised price changes. The output is an elasticity per segment, for example an illustrative demand elasticity of 1.5 in the toy run below, and ideally a supply elasticity too. Treat both as estimates with intervals, not constants. What you now know: elasticity needs causal variation in price.

Step 3: Test prices with switchbacks, not user splits

A user-level A/B test fails because riders share drivers. When treated riders see a higher price and request less, more drivers are free for the control group, so control riders get a ride more often than if everyone kept the old price (0.584 against 0.545), and treated riders less often than under a full rollout (0.584 against 0.628). Both gaps shrink the measured difference. In the toy run a rollout of a 20% higher price raised revenue per rider from 0.450 to 0.540, an effect of 0.090, while the user-level test measured 0.020.¹ Interference is the effect in which one unit's treatment changes another unit's outcome.

A switchback experiment avoids it. Bojinov, Simchi-Levi and Zhao describe it as sequentially exposing an experimental unit to random treatments, and call the length of time a treatment persists in impacting the outcome the order of the carryover effect. A carryover effect is the leftover influence of the previous block's price (Bojinov et al., 2020). Short blocks add carryover bias; long blocks leave fewer blocks. Randomise the market, not the user.

Text description of the diagram

• A rollout of a 20% higher price lifts revenue per rider by 0.090 in the toy run.
• The user-level A/B test measured 0.020.

Step 4: Forecast per area and set a capped multiplier

The input is a forecast of demand and supply for each small area and window, such as a hexagon of a few hundred metres and the next five minutes. Serve it from streaming counts of requests, open driver sessions and recent completions, fed to a model that outputs expected demand and supply at the base price. With the two elasticities, the clearing multiplier solves demand equals supply.

With an illustrative demand elasticity of 1.5, supply elasticity of 0.5 and demand at twice supply at the base price, the multiplier is 2 raised to the power of one over two, which is 1.41.¹ Apply a cap and smooth changes over time, so the multiplier does not jump between windows. If the cap binds, the system stops clearing the market: with demand six times supply and a cap of 2.0, only 66.7% of the riders who still request at the capped price are served.¹ What you now know: the multiplier is a bounded solution to a forecast.

Step 5: Serve, explain and monitor the feedback loops

Serve the multiplier through a low-latency lookup keyed by area and show it to the rider before the request, with a clear explanation. Log every price shown, the forecast behind it and the outcome, because those logs are the training data for the next version and the audit trail for regulators.

Prices feed back into other systems. A higher multiplier changes arrival times and cancellations, so the pricing model and the estimated time of arrival (ETA) model influence each other, and dispatch reads both. Keep a small holdout region under the previous rule to measure drift. Hall and colleagues describe the evidence of failure too: when the surge algorithm broke down for 26 minutes on New Year's Eve, the rate at which requests were fulfilled fell sharply. What you now know: the system needs an off-switch and a baseline.

1 · Objective2 · Elasticity3 · Switchback4 · Capped multiplier5 · MonitorReplay

Step-by-step description

1. Trips, wait and fairness limits.
2. From experiments or a discontinuity.
3. Randomise by time block.
4. Per-area forecast, smoothed.
5. Log prices, keep a baseline.

• The objective and guardrails come before the model.
• Elasticity is estimated from causal variation in price.
• Switchback experiments randomise the market by time block.
• The multiplier is capped and set per area from a forecast.

Worked example

Three calculations, all on illustrative inputs, with the script saved beside the page.¹

The clearing multiplier. With illustrative elasticities of 1.5 for demand and 0.5 for supply, the multiplier that equates demand and supply is the ratio of demand to supply at the base price, raised to the power 1 / (1.5 + 0.5).

The user-level test. The toy market has 200,000 riders and 90,000 drivers. Completion probability is 0.545 when everyone sees the base price, 0.628 when everyone sees a price 20% higher and 0.584 in a half-and-half test, so treated riders' lower demand helps the control group.¹

The switchback. A toy market of 28 days with a daily demand cycle has a true effect of 20.59 revenue units an hour. Randomising hourly blocks gives a mean estimate of 10.46, a bias of 10.13, because the first half hour after each switch carries the old price. Four-hour blocks reduce the bias to 2.93 but raise the spread of the estimate (its standard deviation across 1,500 random assignments) from 8.22 to 14.79. The spread comes from blocks landing on different parts of the daily cycle, which is why stratifying by time of day helps.¹

Blocks of a full day, aligned with the daily cycle, give a bias of 0.33 and a spread of 1.85, but every whole-day block holds the full daily cycle, so the blocks barely differ, and this toy has no weekday pattern, so treat that row with care.¹

Text description of the diagram

• With hourly blocks the switchback estimate is biased by 10.13 revenue units.
• With 8-hour blocks the bias is 2.18 but the spread of the estimate is 15.47.

Trade-offs and edge cases

Dynamic pricing trades efficiency against trust, and every design choice moves that balance.

• Cap and smoothing. A cap protects riders and limits regulatory risk, but when it binds the market no longer clears, as the table shows.
• Fairness across markets. A multiplier that is affordable in one city may not be in another with lower incomes; set caps and rules by market, and review who is priced out.
• Experiment design. Pair switchbacks with stratification by time of day, and keep a guardrail on wait time so an experiment cannot harm service.
• Host-side pricing. For listings, the system suggests a price to a host who decides, so the objective is the host's bookings and the model is a recommendation, not a mandate.
• Strategic response. Drivers and riders learn the pattern, for example by waiting for the multiplier to fall, so effects drift; see distribution shift.
• Explainability. The rider and the regulator need a reason: show the multiplier, and log the forecast behind it.

For related designs see real-time fraud detection, the feature store walkthrough, batch, streaming and real-time inference and machine learning operations (MLOps).

How to answer it in an interview

The spoken structure: objective, forecast, elasticity, multiplier, experiment, monitoring.

Common mistakes

• "I would predict demand and raise the price in proportion." (wrong) The forecast ignores how demand responds to the price itself. (right) "I would estimate elasticity causally and solve for the clearing price."
• "I would A/B test by user." (wrong) Riders share drivers, so the groups interfere. (right) "I would run a switchback by market and time block."
• "I would learn elasticity from last year's data." (wrong) Prices and demand moved together. (right) "I would use experiments or a discontinuity at price steps."
• "No cap is needed if the model is accurate." (wrong) Accuracy does not address fairness or regulation. (right) "I would cap and smooth, and report who is affected."

Follow-up questions

Design a pricing surge system?

Forecast supply and demand per area and window, estimate elasticities, set a clearing multiplier with a cap and smoothing, and test with switchbacks. In the toy run a demand-to-supply ratio of 2 gives a multiplier of 1.41.¹

How would you design a dynamic pricing model balancing rider affordability with driver earnings across markets with different income levels?

Make the objective multi-part, with caps and elasticities per market. Report completed trips, wait time and rider burden as separate guardrails, and review the effect on lower-income areas before roll-out.

Design the surge pricing algorithm: how do you detect high-demand areas and update prices in real time?

Keep streaming counts of requests, open driver sessions and completions per area and window, forecast the next window, and update the multiplier on a short schedule with smoothing. Alert when the forecast error or the cap-binding rate jumps (anomaly detection in time series).

Why can't you A/B test prices per user?

Riders share one driver pool, so treating some riders changes what the others experience. In the toy run the user-level test measured 0.020 against a true rollout effect of 0.090.¹

What if demand is six times supply and the cap is 2.0?

The clearing multiplier would be 2.45, above the cap. The market then stops clearing: at the capped price of 2.0 only 66.7% of the riders who still request are served.¹ Say which guardrail takes the strain, wait time or unserved requests, and review it by market.

How do you keep surge from feeling unfair?

Cap the multiplier, show it before the request, explain it, smooth changes and review the impact by market. Hall and colleagues note that the rider must acknowledge the higher price before a request is sent.

Sources

1. The Effects of Uber's Surge Pricing: A Case Study (Hall, Kendrick and Nosko; year 2015, month approximate) — Uber Technologies and University of Chicago Booth School of Business, 1 Sep 2015
2. Using Big Data to Estimate Consumer Surplus: The Case of Uber (NBER Working Paper 22627) — NBER (Cohen, Hahn, Hall, Levitt and Metcalfe; month approximate), 1 Sep 2016
3. Design and Analysis of Switchback Experiments (arXiv 2009.00148v1) — arXiv (Bojinov, Simchi-Levi and Zhao), 31 Aug 2020