System Design Interview
On‑demand grocery delivery platform with catalog, cart/checkout, batching, substitutions, and courier assignment.
Single service handling catalog, cart, checkout, and inventory in one place.
What was missing: No edge controls, caching, or async processing.
Why that's risky: Single point of failure; slow checkout under spikes.
What gets added: Nothing yet (MVP).
Trade-offs: Simple and fast to build but not production ready.
Add ingress protection and request governance before business logic.
What was missing: No edge, WAF, or throttling.
Why that's risky: Vulnerable to spikes and abuse.
What gets added: Edge, API gateway, rate limiter.
Trade-offs: Slightly more complex routing.
Distribute traffic across multiple app service replicas.
What was missing: No redundancy or horizontal scale.
Why that's risky: Single instance bottleneck and SPOF.
What gets added: LB and replicas.
Trade-offs: Session management and cache coherence considerations.
Add cache for hot reads and split catalog/cart/checkout services.
What was missing: Hot reads overloaded DB; services tightly coupled.
Why that's risky: Slow catalog and cart UX during traffic spikes.
What gets added: Cache for reads and service separation.
Trade-offs: Cache invalidation and cross‑service coordination.
Use queues and workers to handle post‑order workflows.
What was missing: Checkout blocked on downstream work (payments, assignment, notifications).
Why that's risky: Long tail latencies and timeouts under spikes.
What gets added: Queue and workers for async processing.
Trade-offs: Operational complexity and event contract management.
Introduce payments isolation, delivery tracking, and analytics sink.
What was missing: PCI isolation, delivery tracking, and analytics sink.
Why that's risky: Payment faults or analytics load could impact checkout.
What gets added: Dedicated payments/delivery services and analytics consumer.
Trade-offs: More services and operational overhead.
Add CDN for static assets and Blob storage for media, keeping all core services from earlier stages.
What was missing: Edge caching for static/media without losing core services.
Why that's risky: High origin load and latency for images and static assets.
What gets added: CDN and blob storage while retaining payments, delivery, queue/workers, and analytics.
Trade-offs: Cache invalidation and signed URL management.
Add inventory reservations and outbox pattern while keeping all prior services (CDN, media, payments, delivery, queue/workers).
What was missing: Idempotent writes, inventory reservations, and reliable event publication without losing prior services.
Why that's risky: Duplicate charges/orders on retries; lost events on crashes.
What gets added: Inventory service + DB, Outbox store + relay to queue.
Trade-offs: Extra storage (outbox) and operational complexity.
Add dedicated search and recommendations while preserving all transactional paths.
What was missing: Fast search and browse plus personalized discovery without disrupting OLTP path.
Why that's risky: DB scans for search; mixing OLTP and search workloads.
What gets added: Search API + Index + Indexer + Recommendations; existing queue used for updates.
Trade-offs: Eventual consistency between source of truth and index.
Add regional ingress, read replica, and monitoring while preserving the full system.
What was missing: Regional ingress and read replicas with end‑to‑end observability.
Why that's risky: Single‑region outage would halt orders; limited visibility for incident response.
What gets added: Active‑active edges/APIs, read replica for orders, and monitoring/tracing.
Trade-offs: Cross‑region consistency and operational complexity.
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:
