Design ETA Prediction

It sounds like a maps problem and it is mostly not. The number a consumer sees on a restaurant card, "37 min," and the number again at checkout, and the live estimate that ticks down while their food is out for delivery, are all predictions. They come from a model that has learned how long this restaurant takes to cook at this hour. It also knows how long it takes to find a Dasher right now, and how long the drive will be. The same prediction feeds dispatch, which decides who to assign partly on how each choice moves the delivery time. So this is an ML system: feature engineering, a trained model, a training loop that feeds a serving path, with geography as one input among many.

The DoorDash angle

Frame it as a prediction problem. Treat it as GPS streaming and you've walked into the wrong design. A nearby interview prompt, "track the Dasher on a live map," is about ingesting a firehose of location pings and fanning them out. ETA is the opposite shape. The hard part isn't moving dots around, it's guessing a future time accurately from messy signals, then being right often enough that consumers trust the app and dispatch makes good calls. Say that in the first minute. The words to reach for are "feature store, model serving, retraining," not "geohash and websockets." Lock the framing early and the rest of the hour gets easier.

Anchor the scale. DoorDash delivers on the order of several million orders a day, so call it roughly 7 million completed deliveries every day, which matters twice. Every finished delivery is a labeled training row, so the training set grows by millions of examples daily. And every active delivery wants its ETA refreshed as it moves through the kitchen and onto the road. Predictions fire far more often than orders do. Add the browse case, where a consumer scrolling the home feed sees an estimate on every restaurant tile, and the read volume climbs into the hundreds of thousands per second.