Food Delivery, End to End
hardOpen designVery commonly asked~45 minHLD roundBar raiserHiring managerSenior / SDE-3SwiggyFlipkartUberAmazonGooglePhonePeGeospatialQueues & AsyncConsistency & ConsensusStorage & Data Modelling
The question, as asked
“Design Swiggy. A user orders, a restaurant cooks, a rider picks it up and delivers it — and everyone wants to know where the order is.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Three-sided marketplace — customer, restaurant, rider. Ask which side they want depth on; trying to cover all three evenly in 45 minutes means covering none of them well.
- Scale: orders per day, peak orders per minute, active riders, and restaurants per city. Peak matters far more than average here — dinner hour is several times the daily mean.
- Is assignment batched or immediate? Batching riders every few seconds gives much better matches than greedy per-order assignment, and it changes the core algorithm.
- How accurate must the ETA be, and is it a promise or an estimate? A promised delivery time with refunds attached is a different system from a hint.
- Does the restaurant confirm the order, or is acceptance automatic? Manual confirmation introduces a human in the critical path and a timeout policy you have to design.
- Scope out payments unless they ask — say 'I'll treat payment as an external service with an idempotent authorise and capture' and move on, so you spend your time on the matching and tracking.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.