Design: Delivery ETA Prediction
Predicting delivery arrival times by combining route distance, traffic patterns, restaurant prep time, and driver behavior.
The Problem
Design a system that predicts how many minutes a food delivery will take when a customer places an order. The prediction appears on the order confirmation screen. Accuracy matters because customers get upset when delivery is much later than promised, and the platform loses money if it consistently promises faster delivery than reality.
Breaking Down the ETA
Total ETA is not one prediction. It is the sum of multiple stages:
Total ETA = Order Acceptance Time + Food Prep Time + Driver Assignment Wait
+ Pickup Travel Time + Delivery Travel Time + Last-Mile Time
Customer places order
│
▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Restaurant │───►│ Driver │───►│ Drive to │───►│ Deliver to │
│ accepts and │ │ assigned and │ │ customer │ │ customer │
│ prepares food│ │ picks up food│ │ (route time) │ │ (last mile) │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
Prep Time Assignment Time Travel Time Last Mile
(5-30 min) (2-15 min) (5-25 min) (1-5 min)
You can either predict total ETA end-to-end with one model or predict each stage separately and sum them. In practice, a combination works best: use sub-models for stages with very different feature sets and a final model that adjusts the total.
Features
Static Features (Change Slowly)
- Restaurant average prep time (from historical orders).
- Route distance in kilometers between restaurant and customer.
- Restaurant type and cuisine (pizza is faster than sushi).
- Customer address complexity (apartment building versus standalone house).
Dynamic Real-Time Features (Change Constantly)
- Current number of pending orders at the restaurant (if they have 15 orders queued, prep takes longer).
- Number of available drivers nearby.
- Real-time traffic congestion on the route (from map APIs).
- Current weather (rain slows everything down).
- Time of day and day of week (lunch rush versus 3pm lull).
Historical Patterns
- This restaurant's average prep time on Fridays at 7pm.
- This driver's average speed and delivery completion time.
- Historical travel time on this route segment at this time of day.
Model Architecture
A gradient boosted tree model (XGBoost, LightGBM) works well here because the data is tabular with a mix of categorical and numerical features.
The target variable is the actual delivery time in minutes. Train with Mean Absolute Error (MAE) or quantile regression. Quantile regression is especially useful because you can predict the median (50th percentile) for the display ETA and the 90th percentile to set an upper-bound promise.
Key Design Challenges
- Asymmetric Errors: Being 10 minutes late is worse than being 10 minutes early from the customer's perspective. Use asymmetric loss functions that penalize underestimates more than overestimates.
- Dynamic Updates: After the order is placed, conditions change (driver gets stuck in traffic). Update the ETA dynamically as new real-time information arrives.
- Restaurant Variability: The same restaurant might prepare food in 10 minutes on a quiet Tuesday and 35 minutes during Friday dinner rush. Features must capture this variability.
- Cold Start: New restaurants have no historical data. Use category-level averages as starting estimates and update as orders accumulate.
Evaluation
- Mean Absolute Error (MAE): Average absolute difference between predicted and actual delivery time.
- Percentage within 5 minutes: What fraction of predictions are within 5 minutes of the actual delivery time.
- Late Rate: What fraction of deliveries arrive after the promised ETA. This is the metric customers care about most.
Say this out loud
Delivery ETA prediction breaks down into restaurant prep time, driver assignment wait, route travel time with real-time traffic, and last-mile delivery. The model uses both static features like route distance and dynamic features like current restaurant queue length and traffic congestion. Asymmetric loss functions penalize underestimates more heavily because late deliveries hurt customer trust.
Followups to expect
- How do you handle ETA for new delivery zones? Start with map-based route time estimates plus category-average prep times. Refine as real delivery data accumulates in the new zone.
- Should you show a point estimate or a range? Showing a range ("25 to 35 minutes") sets more realistic expectations and reduces customer frustration when delivery falls within the range but past a single point estimate.
Check yourself
Why is predicting food delivery ETA harder than predicting route travel time alone?