A food delivery ETA estimation system is the invisible service that answers a single, high-stakes question for every food order on the planet: “How many minutes until this specific meal is at this specific door?” It must answer that question in a few tens of milliseconds, update it as reality unfolds, and be within a couple of minutes of the truth — every single time.

Under the hood, it is not one prediction. It is a chain of predictions — how long the merchant takes to prep, how long a courier takes to arrive, how long the pickup takes, how long the drive takes, and how long the last hundred metres take — all stitched together and continuously re-estimated as the order progresses.

Before designing one, we need to pin down exactly what the system does — and what it does not. “Predicting a delivery time” sounds simple, but a modern ETA service is a stack of forecasts, constraints and business rules.

2.1 A Working Definition

A food delivery ETA estimation system is a real-time service that, given the current state of an order (merchant, items, courier, geography, weather, marketplace conditions), returns:

• a point estimate in minutes for when the customer will receive the order,
• a confidence range (e.g. 22–27 min) that reflects real uncertainty,
• a break-down across the phases: prep, courier travel to store, wait at store, drive to customer, hand-off, and
• a versioned decision so we can audit which model produced which number for which order.

2.2 Where You Encounter It

2.3 What It Is Not

An ETA system is not a routing engine, a dispatch optimiser, or a mapping service — even though it depends on all three. It is a prediction layer that consumes their outputs, blends historical experience with live signals, and emits a number a human can act on.

On a food delivery platform, the ETA is the single number the customer looks at more than any other. It shapes willingness to order, tolerance for delay, and the emotional experience of the entire wait. Getting it right is not a nicety — it is a foundational unit of platform trust.

3.1 The Business & Human Problem

• Conversion at checkout falls off a cliff once the ETA crosses ~40 minutes; even a two-minute improvement is worth measurable revenue.
• Contact rate to customer support spikes for orders that arrive later than promised — each contact costs money and lowers CSAT.
• Refund and credit exposure is directly proportional to the number of orders that miss their promised time by a certain margin.
• Courier utilisation depends on accurate ETAs: too optimistic and couriers stack up outside restaurants, too pessimistic and the fleet is over-supplied.
• Merchant fairness hinges on the ETA correctly attributing delays — a slow ETA that is really the courier’s fault must not damage the restaurant’s ratings.

3.2 What Makes It Uniquely Hard

A production ETA system is roughly a dozen components co-operating. Each has one narrow job. Understanding them separately is the first step to designing the whole thing.

The quality of an ETA is bound by the quality of its signals. Weak features guarantee a weak model, no matter how sophisticated the architecture. This chapter catalogues the signals that actually move the needle.

5.1 The Four Signal Families

5.2 A Minimal Feature Vector

{
  "order_id"           : "o_44e1",
  "items_count"        : 6,
  "prep_heavy"         : true,
  "menu_tags"          : ["pizza", "salad"],
  "merchant_id"        : "m_512",
  "merchant_prep_p50_5m": 11.2,
  "merchant_queue"     : 4,
  "courier_transport"  : "moped",
  "courier_to_store_km": 1.4,
  "courier_active_orders": 1,
  "store_to_cust_km"   : 3.2,
  "traffic_index_zone" : 0.68,
  "weather_rain_mm_1h" : 3.1,
  "address_type"       : "apartment_gated",
  "day_part"           : "friday_dinner"
}

5.3 Live vs Pre-Computed Features

Some features must be freshly measured on every request (courier distance, current queue). Others can be pre-computed hourly and cached (merchant p50 prep by day-part, zone travel-speed matrix). A hybrid design — hot signals from Redis / streaming feature store, cold aggregates from batch — is what makes sub-50 ms serving possible.

Once the features exist, the interesting question is what turns them into minutes. There is no single “ETA model.” Every mature system uses a layered mix of heuristics, per-phase regressors and marketplace overrides.

6.1 Heuristics & Baselines

Every stack starts with a rule-based baseline: ETA = merchant.avg_prep + haversine(store, customer) / avg_speed + buffer. It is bad at extremes but great as a floor and as a fallback when models are unhealthy.

6.2 Per-Phase ML Regressors

6.3 End-to-End Models

Some platforms train a single deep model that outputs the whole ETA (often a transformer or graph neural network over city road networks). They win on accuracy in the average case but are harder to explain, debug and roll back. Most stacks use per-phase models plus an end-to-end “critic” that catches obvious mistakes.

6.4 Quantile Regression & Uncertainty

The customer does not just want a number, they want a reliable number. Quantile regression produces P50 (median), P90 (safe promise) and P10 (best case) at once. The displayed ETA is often a policy blend such as ETA_display = clamp(P70, floor=P50+1, ceil=P95).

features = fetch_features(order)

// 1. baseline heuristic (always available)
base = heuristic_eta(features)

// 2. per-phase predictions
prep    = prep_model.predict(features)
to_stor = travel_model.predict(features, leg="courier_to_store")
wait    = handoff_model.predict(features, phase="store_wait")
to_cust = travel_model.predict(features, leg="store_to_customer")
last_m  = handoff_model.predict(features, phase="dropoff")

// 3. blend + guardrails
eta = fuser.combine([prep, to_stor, wait, to_cust, last_m])
eta = policy.apply(eta, city=features.city, tier=features.tier)

// 4. safety net
if abs(eta - base) > base * 0.5:
    eta = policy.reconcile(eta, base, reason="model_out_of_bounds")

return eta_with_interval(eta)

Two architectural axes must be picked early: how often the ETA is recomputed, and how the compute is spread. Both decisions have long, expensive tails.

7.1 When Does the ETA Recompute?

• Request-driven — whenever any client (checkout, tracking, dispatcher) asks. Guarantees freshness but hits the model hard.
• Event-driven — when order lifecycle events fire (accepted, ready, picked-up). Push the ETA to clients over websocket / SSE.
• Time-driven — every N seconds while an order is in flight, to keep the tracking screen accurate.

Serious systems use all three: request-driven for checkout, event-driven for major state changes, and time-driven for the tracking countdown.

7.2 Streaming, Micro-Batch or Batch?

7.3 Deployment Shape

7.4 Sharding Strategy

City is the natural unit of scale — road network, merchant mix and fleet mode differ per city. A common pattern is region → city → zone sharding for models and feature stores, with a global façade for cross-region traffic. Order state itself is partitioned by orderId in the event stream.

Let us follow one real order — a Friday night pizza — from the checkout screen to the doorbell, and watch how the ETA is produced, updated and (hopefully) honoured along the way.

The non-functional targets for an ETA system have their own personality. Accuracy matters, but so does calibrated bias, smoothness of updates, and honest handling of uncertainty.

9.1 The Latency Budget

Every food delivery platform, sooner or later, ships the same handful of ETA bugs. Knowing them turns a full quarter of firefighting into a paragraph in a design review.

10.1 Ten Traps We’ve All Fallen Into

10.2 The Trade-offs You Cannot Avoid

Food delivery ETAs have been on a decade-long journey from “guess and hope” to “calibrated marketplace forecast.” Understanding the waves helps you place your own platform.

11.1 Adjacent Systems That Plug In

An ETA system is one of those quiet pieces of infrastructure whose quality shapes the entire product. Nobody says “wow, what a great ETA” — but everyone feels a broken one, immediately.