Real architecture · Senior
Real-time dispatch: order, courier, and kitchen time
It is the real counterpart of case_food_delivery. "Nearest" is not enough: it batches only if no order is delayed, the vehicle depends on weight and distance, phone battery counts, and dispatch depends on predicted kitchen time.
Short answer
It is the real counterpart of case_food_delivery. "Nearest" is not enough: it batches only if no order is delayed, the vehicle depends on weight and distance, phone battery counts, and dispatch depends on predicted kitchen time. When the customer completes the order, the platform passes the information to the restaurant, which may or may not accept it.
01 · CONTEXT AND REQUIREMENTS
From order to the right courier
When the customer completes the order, the platform passes the information to the restaurant, which may or may not accept it. At iFood Delivery restaurants, iFood runs all delivery logistics and the restaurant can focus on producing the dish.
The dispatch problem iFood describes is finding the best courier for each order, so that the courier arrives at the restaurant on time and then takes the order to the customer's home. The difficulty is that orders are created all the time, scattered across the city, and couriers are also moving all the time.
In the diagram, the order leaves the customer's app and reaches the order platform.
The platform passes the order information to the restaurant.
The restaurant has about 8 minutes to confirm the order; without confirmation, the order is automatically canceled.
At iFood Delivery restaurants, iFood runs all delivery logistics; this is the stretch the rest of the case explores in depth.
02 · TIME PREDICTION
Two predictions before dispatching
A machine learning model builds delivery-time predictions for a given restaurant, delivery radius, and day and time of the week. The model also predicts order kitchen time, crucial information for deciding when to send the courier to the restaurant.
This model can predict delivery and kitchen times from the situation at the moment, which is why these times vary across hours and days.
According to iFood's head of Logistics Development, having an accurate preparation-time model lets the courier arrive at the exact moment the order is ready, without affecting the customer experience.
03 · FLEET STATE
What dispatch needs to know right now
Dispatch receives a constant data stream from all connected couriers, with positions, connectivity status, battery level, and other information. It needs to know the whole fleet, the positions, and who can or cannot take an order at that moment.
Battery is iFood's own example: with very low charge, it may conclude that the courier will not be able to complete the delivery, since the phone may die midway. In the text aimed at couriers, having at least 15% battery and GPS calibrated to high accuracy appears as a good practice for using the app.
The courier app sends iFood a constant stream with position, connectivity status, and battery level.
In the diagram, this stream enters an event queue before being consumed.
In the diagram, the events update the fleet state, which holds the current situation of each courier.
The optimizer needs to know the whole fleet, the positions, and who can or cannot take an order right now.
With very low battery, iFood may conclude that the courier will not be able to complete the delivery.
04 · DISTRIBUTION CRITERIA
Nearest is not enough
iFood states that it distributes orders to couriers according to a set of criteria, using data intelligence and algorithms. The table summarizes the criteria the text lists.
| Criterion | What the text says |
|---|---|
| Proximity to demand | Couriers closer to areas of intense demand are prioritized |
| Dedication to a region | Dedicated couriers receive that region's orders before others |
| Time scheduling | Those who schedule in advance the hours they will be available are prioritized |
| Good use of the app | Adoption of good practices that ensure the app works well and deliveries are high quality |
| Order needs | Weight and payment method |
Good use of the app is being updated to become the Score, a number that sets the courier's level according to their usage history; the better the Score, the higher the priority. According to the text, this novelty was only available in specific areas.
Among the order's special needs are weight and payment method. The text shows how distance and order weight factor into the choice of vehicle.
| Order type | Prioritized vehicle |
|---|---|
| Short route, light order | Bicycle, usually |
| Longer route, items that fit in the bag | Moto |
| Bulky purchase, such as groceries | Carro |
05 · ROUTES AND BATCHING
Optimizing routes without delaying anyone
The optimization algorithm tests many hypotheses for creating routes between orders and couriers. The goal is to minimize any delay and create shorter routes, which frees the courier sooner for the next delivery. These decisions are made minute by minute.
There are constraints: for example, do not choose a courier whose distance to the restaurant is so large that it makes on-time delivery infeasible.
iFood also creates routes for batched orders, such as when the courier's bag carries five pizzas to different locations. It only does this if none of the orders will be late relative to what was promised to the consumer.
Delivery promises are among the most important factors in setting up the route's timing.
Predicting kitchen time is crucial information for deciding when to send the courier to the restaurant.
In the diagram, the fleet state reaches the optimizer together with the orders and the predictions.
The algorithm tests many route hypotheses, aiming to minimize any delay and create shorter routes.
One of the constraints is not to choose a courier whose distance to the restaurant makes on-time delivery infeasible.
The goal is to find the best courier for the order, so that the courier arrives at the restaurant on time.
06 · OPERATIONS AND LIMITS
Monitor, prioritize delays, and know the limits
Live monitoring tracks each city with iFood Delivery. It checks whether there are enough couriers for the number of orders, whether any region is imbalanced, and tracks late orders.
When an order is late, iFood opens an automatic internal incident and started prioritizing the delivery.
On another layer, statistical and operations research models predict how many orders should arrive during a shift in a city and how many partner couriers need to be available in that period. For the head of Logistics Development, balancing restaurant, partner courier, and end consumer is the main challenge.
Frequently asked questions
What is Real-time dispatch: order, courier, and kitchen time?
It is the real counterpart of case_food_delivery. "Nearest" is not enough: it batches only if no order is delayed, the vehicle depends on weight and distance, phone battery counts, and dispatch depends on predicted kitchen time.
What does the Real-time dispatch: order, courier, and kitchen time design cover?
It is organized in these sections: From order to the right courier, Two predictions before dispatching, What dispatch needs to know right now, Nearest is not enough, Optimizing routes without delaying anyone, and Monitor, prioritize delays, and know the limits.
How long is Real-time dispatch: order, courier, and kitchen time and what level is it?
It takes about 17 minutes to read and is rated Senior level.
Now design it yourself
Run this case as an interview in the System Design school: you make the decisions, the tutor challenges them and you see how your design scores.