Food delivery dispatch is a matching problem where nothing stands still. Orders arrive every second, riders are moving, restaurants cook at different speeds, and a decision that was right 30 seconds ago is wrong now. In this lab you'll design the dispatch system for a delivery app from a blank page, modelled on a product like Swiggy. You'll see that the "find the nearest rider" answer everyone starts with is the wrong one, and why.
The brief
Customers order food from restaurants. Riders on scooters pick it up and deliver it. Dispatch is the part that decides which rider gets which order, and when.
The people involved:
- Customers, who want their food fast and want to see where it is.
- Restaurants, who don't want a rider waiting 15 minutes at the counter, or food going cold waiting for one.
- Riders, who are paid per delivery and want a steady stream of nearby work.
In scope:
- Tracking where every active rider is.
- Assigning orders to riders, including giving one rider two orders that are on the way.
- Riders accepting or rejecting offers.
- Re-assigning when things go wrong.
Out of scope:
- Placing the order, payments and menus.
- Turn-by-turn navigation (use a maps provider).
- Rider pay calculation and surge pricing.
- Live tracking on the customer's map. The Module 6 lab covers that.
Requirements
Functional
- Riders send their location while on shift.
- When an order is placed, the system assigns a rider so they arrive at the restaurant about when the food is ready.
- A rider receives an offer and can accept or reject within a short time.
- A rider can carry two orders at once if both are on a similar route (batching).
- If a rider rejects, goes offline or is badly delayed, the order is reassigned.
- Every order gets exactly one rider at a time. Two riders never turn up for the same order.
Non-functional
- Fast decisions: an order should have its first rider offer within 30 seconds at the 95th percentile. How fast the rider accepts is up to the rider; the offer's short expiry (below) bounds it.
- Good decisions: minimise total delivery time and rider idle time, not just distance for one order.
- Correct: one active rider per order, and no rider holding more orders or live offers than they can carry. No double assignment, ever.
- Survives peaks: dinner time is 4× the daily average, and rain doubles it again (more orders, fewer riders).
- City-local failures: a problem in one city must not stop dispatch in another.