Getting Ready: Food Delivery Service

Online food delivery is a $350+ billion global industry. Platforms like Swiggy, Zomato, DoorDash, UberEats, Grubhub, and Deliveroo process millions of orders daily — Swiggy alone handles over 2 million orders per day across 500+ Indian cities. Behind every "Your food is on the way" notification, there's an object model coordinating three independent parties in real time: the customer who ordered, the restaurant preparing the food, and the delivery partner racing across town.

What makes the Food Delivery System an excellent hard-difficulty LLD problem is the convergence of several non-trivial design challenges:

• Three-sided marketplace — Unlike most systems that have one or two actor types, food delivery has three distinct stakeholders (Customer, Restaurant, Delivery Partner) with different capabilities, different views of the same order, and different state transitions they trigger. Modeling this cleanly requires careful separation of concerns and well-defined interfaces.
• Complex order lifecycle — An order passes through 7+ states: Placed → Confirmed → Preparing → Ready for Pickup → Out for Delivery → Delivered (or Cancelled at various points). Each transition is triggered by a different actor — the customer places, the restaurant confirms and prepares, the driver picks up and delivers. This is a textbook application of the State Pattern.
• Delivery assignment algorithm — When food is nearly ready, the platform must assign the best available delivery partner. "Best" depends on the strategy: nearest driver, highest-rated driver, or a weighted score combining distance, rating, and current workload. This is a textbook application of the Strategy Pattern.
• Real-time tracking and notifications — Every status change triggers notifications to different stakeholders: the customer sees live tracking, the restaurant sees order progress, the delivery partner receives pickup instructions. This is a natural Observer Pattern application.
• Cart-to-order pipeline — Customers build a cart (restricted to items from a single restaurant), then convert it to an order. The cart is ephemeral; the order is persistent. The price captured at order time must be immutable (even if the restaurant updates prices later).

This problem appears in LLD interviews at companies like Amazon, Uber, Flipkart, Paytm, and Swiggy itself because it tests whether candidates can model a multi-stakeholder, event-driven system with complex state management — not just a single-entity CRUD application.

By the end of this design problem, you will be able to:

• Model a three-sided marketplace — design classes where customers, restaurants, and delivery partners each have distinct responsibilities, capabilities, and interactions with orders
• Design a state machine for order lifecycle — apply the State Pattern to manage 7 order states with transitions triggered by different actors, ensuring only legal transitions are allowed
• Implement delivery assignment algorithms — apply the Strategy Pattern to support multiple driver assignment strategies (nearest, highest-rated, weighted score) without modifying the core delivery logic
• Build real-time notification infrastructure — use the Observer Pattern to fan out order status changes to customers (tracking), restaurants (order board), and the analytics system
• Handle cart-to-order conversion — model the ephemeral cart and the persistent order, with price snapshotting to protect against mid-order price changes
• Create four UML diagrams — Use Case Diagram (three actors), Class Diagram (structural blueprint), State Machine Diagram (order lifecycle), and Sequence Diagram (place-order flow)
• Write complete implementations in Python and Java that match the UML designs exactly
• Apply and justify three design patterns — State (order lifecycle), Strategy (delivery assignment), and Observer (real-time tracking) — explaining why each fits and what alternatives were considered

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (a Restaurant composes its Menu of MenuItems) and Association (an Order references a Customer, a Restaurant, and a DeliveryPartner) — Fundamentals S4
• Inheritance & Polymorphism — used less for entity hierarchies here and more for pattern-based polymorphism (state objects, strategy objects, observer interfaces) — Fundamentals S3
• State Pattern — how objects delegate behavior to state objects, and how transitions change the current state — Fundamentals S12. This is the central pattern of this problem.
• Strategy Pattern — how interchangeable algorithms avoid conditional logic — Fundamentals S12. Applied to delivery assignment.
• Observer Pattern — how subjects notify observers of state changes without coupling — Fundamentals S12. Applied to real-time tracking.
• UML Class Diagrams — reading class boxes, relationship arrows, and multiplicities — Fundamentals S5
• UML State Machine Diagrams — reading states, transitions, guards, and events — Fundamentals S5
• UML Sequence Diagrams — reading lifelines, messages, and activation bars — Fundamentals S5

If you've completed the Online Shopping System (DP20) and the Ride-Sharing Service (DP22), you've already worked with order state machines and location-based matching. This problem combines both challenges with the added complexity of a three-party coordination system.

We will design: The core domain logic of a Food Delivery System — customer browsing and cart management, restaurant menu and order acceptance, delivery partner assignment and tracking, order lifecycle through 7 states, payment recording, and real-time notifications. All modeled as an object-oriented system with clear class hierarchies and design patterns.

We will NOT design: Database schemas, REST API endpoints, distributed systems, recommendation engines, real GPS tracking, payment gateway integration, search/ranking algorithms, promotional offers, or delivery fleet optimization. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Key distinction from similar problems:

• Unlike the Online Shopping System (DP20), which models a buyer-seller marketplace with warehousing and shipping, the Food Delivery System manages real-time perishable delivery where timing is critical — food must reach the customer within 30-45 minutes, and the delivery partner is dynamically assigned, not predefined
• Unlike the Ride-Sharing Service (DP22), which matches one rider with one driver for a trip, the Food Delivery System involves three parties per order and the restaurant performs work (food preparation) between the request and the delivery — adding intermediate states that ride-sharing doesn't have
• Unlike the Restaurant Management System (DP29), which models a single restaurant's internal operations (tables, kitchen, waitstaff), the Food Delivery System models a platform aggregating many restaurants — the platform owns the order lifecycle, not anysingle restaurant