Design ETA Prediction for Food Delivery and Ride-Hailing Apps

The question: design the system that predicts delivery time for a food delivery app (or arrival time for a ride-hailing app). The estimate is shown before ordering, updated during the order, and used internally for dispatch and pricing. Customers punish late deliveries more than early ones, the inputs change by the minute, and the prediction is requested millions of times a day.

1. Clarify requirements

2. Frame it as an ML problem

Regression on minutes. Decompose the journey so each part can use the right signals and be debugged on its own:

Because lateness hurts more than earliness, predict quantiles (P50 and P80/P90) with a quantile loss, or a distribution, rather than only a mean. Show the customer a range or a slightly conservative point.

3. Data

• Completed orders with timestamps for every stage: placed, confirmed, food ready (where known), courier arrived, picked up, delivered.
• Labels are clean and plentiful: actual durations, available within an hour.
• Food-ready time is often missing or noisy (restaurants tap late); infer it from courier wait times.
• Time-based splits; rolling backtests across weeks to capture weekly and holiday patterns. See training data.

4. Features

Real-time kitchen load and courier supply come from stream processing into an online store; historical aggregates come from daily batch jobs. See feature engineering.

5. Model

1. Baseline: routing-engine travel time + restaurant's average prep time for that hour.
2. Gradient-boosted trees per stage with quantile loss: strong, fast and explainable.
3. Deep model that learns from sequences (route segments, recent orders at the restaurant) and predicts the residual on top of the routing engine's estimate, a common approach in industry.
4. Post-processing: add a buffer when uncertainty is high; clip to sensible bounds.

6. Architecture

Search ETAs : 50K req/s × 40 restaurants = 2M estimates/s → too many model calls;
              cache per (restaurant, delivery area hexagon) for 60 s:
              ~200K open restaurants × ~20 nearby hexagons = 4M keys, mostly hot
Checkout    : 10M orders/day ≈ 115/s avg; exact per-order prediction, no cache
In-flight   : re-predict on each stage event and every ~2 min from courier GPS

7. Evaluation

• Offline: MAE overall and per stage; percentage within ±5 minutes; lateness rate (actual > shown); quantile calibration (does the P90 cover 90% of orders?).
• Slices: peak vs off-peak, rain, new restaurants, large orders, cities.
• Online: customer complaints and refunds for lateness, conversion at checkout (pessimistic ETAs lose orders), dispatch efficiency.
• See ML evaluation.

ETA is a good place to show a business trade-off: an ETA that's too optimistic increases orders now but causes late deliveries and churn; one that's too pessimistic loses orders. The displayed quantile is a product decision tested online.

8. Monitoring

• Live error dashboards per city and stage; alert when lateness rises above a threshold for an area.
• Feature freshness of courier supply and kitchen load streams.
• Drift during events (storms, sports finals, holidays); fall back to a conservative buffer when inputs look abnormal.