System Design Interview
Quick-commerce grocery delivery inspired by Swiggy Instamart, Zepto and Blinkit: addresses mapped to dark stores, per-store catalogs and stock reservations, orders pushed to pickers in aisle order, riders waiting at the store, and capture-on-delivery payments. A teaching design.
See why a national catalog and a single stock number can't deliver in ten minutes.
What was missing: Nothing yet.
Why that's risky: A shopper sees items their nearest store doesn't have, two orders can take the last unit, and evening spikes swamp one server.
What gets added: One server showing a national catalog and placing orders against a central stock count.
Trade-offs: Simple, but stock isn't where the shopper is.
Show only what the shopper's nearby store has, and never sell the same unit twice.
What was missing: One catalog and one stock count for the whole country.
Why that's risky: The order sits in the database: nobody at the store knows to pick it.
What gets added: A store locator that maps the address to its dark store, a catalog showing that store's live stock from a stock cache, and a checkout that reserves each item at that store with a conditional decrement before creating the order with an idempotency key.
Trade-offs: Stock badges come from a cache that can lag a moment; the reservation at checkout is authoritative.
Get each order picked and packed within a couple of minutes.
What was missing: Orders weren't sent to the store.
Why that's risky: Packed orders wait until someone finds a rider.
What gets added: An order event stream partitioned by store, a push channel that sends each order to a picker's handheld with items in aisle order (missing items trigger a substitution offer to the shopper), and a notification worker for status updates.
Trade-offs: Substitutions need the shopper's quick answer; if none comes, the item is refunded.
Hand a packed order to a rider immediately.
What was missing: No rider assignment.
Why that's risky: Shoppers can only browse, not search, and payments aren't captured.
What gets added: Riders check in at their store and send location pings to a rider location service; an assignment worker gives each packed order to a waiting rider, or batches two orders heading the same way.
Trade-offs: Keeping riders at the store costs idle time but makes the ten-minute promise possible.
Let shoppers find products their store actually has.
What was missing: No search.
Why that's risky: Payment capture and abuse protection are missing, and store performance isn't measured.
What gets added: A product search service and index with per-store availability flags, kept current by an indexer reading catalog and stock changes.
Trade-offs: Availability in search lags by seconds; checkout is authoritative.
Charge only for what was delivered, block abuse, and watch each store.
What was missing: Payments weren't captured, and nothing limited abuse or measured store performance.
Why that's risky: Remaining risk is local: a store outage must route its zone to the next-nearest store.
What gets added: A payment worker that captures payment for delivered items only (refunding missing or substituted items), a rate limiter, and monitoring of time to pack, time to deliver, stockouts and substitution rate per store.
Trade-offs: Capturing after delivery means rare failed captures, in exchange for never charging for missing items.
The stages represent a logical progression of architectural improvements, starting from a monolithic design and evolving towards a more scalable, reliable, and maintainable system. Each change was chosen to address specific limitations or risks in the previous stage while preserving existing functionality.
Yes! The provided architecture is a starting point. You can experiment with different designs, add or remove components, and see how it affects scalability, reliability, and performance. The goal is to learn through iteration and exploration.
Feel free to jump ahead or make bigger leaps in the architecture. The stages are meant to guide you, but real-world systems often require non-linear evolution. Just be mindful of the trade-offs and risks associated with larger changes.
Consider the scalability, reliability, fault tolerance, performance, and trade-offs of each change. You can use load testing, chaos engineering, and monitoring to assess how your architecture performs under different conditions.
You can use any technology stack you're comfortable with. Common choices include cloud platforms like AWS, GCP, or Azure for infrastructure, and languages/frameworks like Node.js, Python, Java, or Go for services. The key is to focus on the architectural principles rather than specific technologies.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
