Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Sections
Related Guides
LLD Case Study: Ride-Sharing Booking Engine
Low-Level Design
Concurrency Patterns: Thread Safety, Producer-Consumer, Read-Write Lock & Thread Pool
Low-Level Design
Design Patterns for LLD Interviews
Low-Level Design
Design Uber (Ride-Sharing Platform)
High-Level Design
Design a Multi-Channel Notification Service at Scale
High-Level Design
LLD Case Study: Extensible Rate Limiter
Low-Level Design
LLD Case Study: Food Delivery System
Design the domain model and class hierarchy for a food delivery platform like DoorDash, Uber Eats, or Swiggy. Covers order state machine, Observer-driven notifications, Strategy-based pricing, SOLID principles, thread-safe concurrent order placement, and extensibility for scheduled orders and group orders.
Why Food Delivery Is a Core LLD Problem
Food delivery systems appear in interviews at DoorDash, Uber, Swiggy, and Lyft because they pack several independent design challenges into one coherent domain: state machine correctness (an order must move through legal transitions only), cross-entity coordination (Order, Restaurant, Driver, and Customer all have interdependent state), extensible pricing (surge, promo codes, subscription discounts), and real-time notification (every state change must push to the right parties).
The naive answer — a single Order class with a status string field and methods like cancel() that set the string — fails for two reasons. First, it allows illegal transitions (DELIVERED → PLACED) because there is no enforcement layer. Second, it couples notification, compensation logic, and business rules into one bloated class, violating SRP.
The candidate gap: A mid-level engineer models the entities and draws a class diagram. A senior engineer separates the state machine from the order aggregate, isolates pricing behind a Strategy interface, and wires in Observer for notifications. A staff engineer handles idempotent status updates (out-of-order Kafka events trying to apply a transition twice), thread-safe concurrent order placement, and the extensibility story for scheduled/group orders without touching the core domain.
What Earns Each Level
6/10: Models Order, Restaurant, Driver as classes with fields. Can describe the state transitions. Mentions Observer but can't explain when to use it over direct method calls.
8/10: Implements the state machine with explicit allowed-transition enforcement. Isolates pricing as a Strategy. Wires Observer so Order notifies parties on transition. Identifies SOLID violations in a naive design.
10/10: Handles idempotent transitions (guard against replayed events), thread-safe concurrent placement via per-order locking, compensating actions for cancellation (unassign driver, reverse payment, release inventory). Names production specifics: DoorDash uses a CQRS pattern so the read side (tracking page) is updated via events, not direct DB polls. Discusses extensibility for scheduled orders and group orders without touching core classes.