Requirements for the Food Delivery System

A food delivery platform is a three-sided marketplace — every requirement belongs to one of three stakeholders (Customer, Restaurant, Delivery Partner) or to the platform itself. Let's define what our system needs to do, grouped by domain.

Customer & Account

1. R1: The system shall allow customers to register with a name, email, phone number, and one or more delivery addresses (each with latitude/longitude for distance calculations).
2. R2: Customers shall browse restaurants — filtering by cuisine type, proximity to their delivery address, rating, and availability (open/closed status).

Restaurant & Menu

3. R3: Restaurants shall register with a name, address (with latitude/longitude), cuisine types, and operating hours.
4. R4: Restaurants shall manage their menu — adding, updating, removing menu items, and toggling item availability (e.g., marking an item "sold out" for the day).
5. R5: Each menu item shall have a name, description, price, category (e.g., Appetizer, Main Course, Dessert, Beverage), and an availability flag.

Cart & Ordering

6. R6: A customer's cart shall hold items from only one restaurant at a time. Adding an item from a different restaurant requires clearing the existing cart first.
7. R7: Customers shall add items to the cart, remove items, and adjust quantities.
8. R8: Customers shall place an order from the cart by selecting a delivery address and a payment method.
9. R9: Item prices shall be snapshotted at order placement time. If the restaurant updates a price after the order is placed, the existing order is unaffected.
10. R10: The order total shall be calculated as: sum of (item price × quantity) for all order items, plus a delivery fee.

Order Lifecycle

11. R11: Orders shall transition through a defined state machine: Placed → Confirmed → Preparing → Ready for Pickup → Out for Delivery → Delivered. Each transition is triggered by a specific actor.
12. R12: Restaurants shall accept or reject incoming orders. Acceptance transitions the order from Placed to Confirmed. Rejection transitions it to Cancelled.
13. R13: Restaurants shall mark orders as Preparing (started cooking) and Ready for Pickup (food packaged, awaiting driver).
14. R14: Customers shall be able to cancel an order only before preparation begins — i.e., in the Placed or Confirmed states. Cancellation after preparation starts is not allowed.

Delivery

15. R15: Delivery partners shall register with a name, phone number, vehicle type (Bicycle, Motorcycle, Car), and current GPS location.
16. R16: When an order reaches the Preparing state, the system shall assign a delivery partner using a pluggable strategy (e.g., nearest driver, highest-rated driver, or a weighted-score approach).
17. R17: Only available delivery partners within a configurable radius of the restaurant shall be considered for assignment.
18. R18: Delivery partners shall mark orders as Picked Up (Out for Delivery) and Delivered upon completion.
19. R19: Delivery partners shall update their availability status (Available, On Delivery, Offline) and current location as they move.

Notifications & Tracking

20. R20: Every order status change shall trigger a notification to the relevant stakeholders — the customer receives tracking updates, the restaurant sees order-board changes, and the delivery partner receives pickup/delivery instructions.

Payment

21. R21: The system shall record payments with amount, payment method, and status (Pending, Completed, Failed, Refunded).
22. R22: The system shall support multiple payment methods: Credit Card, Debit Card, UPI, Digital Wallet, and Cash on Delivery.

Beyond functionality, our design must support:

1. Extensibility (Open/Closed Principle): Adding a new delivery assignment strategy (e.g., machine-learning-based scoring) must not require modifying the core order or delivery classes. Similarly, adding new payment methods or order states should be a matter of adding new classes, not editing existing ones.

2. State Safety: The order state machine must enforce legal transitions. It must be impossible to jump from "Placed" directly to "Delivered" or to cancel an order that's already out for delivery. Illegal transitions should be explicitly rejected.

3. Loose Coupling: Stakeholders should be notified of status changes without the Order class knowing who its observers are. Adding a new notification channel (SMS, push notification, email) should require zero changes to the Order or FoodDeliveryService classes.

4. Single Responsibility: Each class should have one reason to change. The Order class manages order state — it doesn't calculate delivery fees, assign drivers, or send notifications. These responsibilities belong to separate classes.

5. Testability: Each component should be testable in isolation — pricing with mock items, delivery assignment with mock locations, state transitions without real notifications.

In Scope:

• Customer registration and delivery address management
• Restaurant registration and menu management
• Cart with single-restaurant constraint and quantity management
• Order creation with price snapshotting
• Complete order state machine (7 states, all transitions)
• Delivery partner registration and availability management
• Delivery assignment with pluggable strategies
• Payment recording (not processing — we don't integrate with real gateways)
• Real-time notification fan-out via Observer Pattern

Out of Scope:

• Restaurant search/ranking algorithms — how Swiggy decides which restaurant to show first is a System Design problem involving geospatial indexing and ML ranking. We model the Restaurant class but not the search infrastructure.
• Real GPS tracking — we model location as a latitude/longitude pair and compute Haversine distance. We don't model real-time GPS streams, map rendering, or ETA prediction.
• Promotional offers & coupons — coupon systems are an extension worth exploring but outside our core design.
• Multi-restaurant orders — some platforms allow ordering from multiple restaurants in one checkout. We enforce single-restaurant carts to keep the state machine manageable.
• Database schemas, REST APIs, distributed systems, UI — this is a Low Level Design exercise.

Every requirement maps to at least one class in our upcoming Class Diagram. Here's a preview of how requirements drive the design:

Requirement Group	Key Classes	Design Pattern
Customer & Account (R1-R2)	Customer, Address	—
Restaurant & Menu (R3-R5)	Restaurant, MenuItem	—
Cart & Ordering (R6-R10)	Cart, CartItem, Order, OrderItem	—
Order Lifecycle (R11-R14)	Order, OrderState (interface), 7 state classes	State Pattern
Delivery (R15-R19)	DeliveryPartner, Delivery, DeliveryAssignmentStrategy (interface)	Strategy Pattern
Notifications (R20)	OrderObserver (interface), concrete observers	Observer Pattern
Payment (R21-R22)	Payment, PaymentMethod (enum), PaymentStatus (enum)	—

The three design patterns (State, Strategy, Observer) map directly to three requirement groups. This isn't coincidence — patterns emerge from requirements, not the other way around.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. The food delivery problem has several ambiguity points worth asking about:

• "Can a customer order from multiple restaurants in one checkout?" — This dramatically changes the data model (one order per restaurant vs. one order with sub-orders). We chose single-restaurant for simplicity, but mentioning the alternative shows design awareness.
• "Should cancellation have time-based penalties?" — We allow free cancellation before preparation. Some platforms charge a fee during the Confirmed state. Asking this shows you think about edge cases.
• "Who triggers delivery partner assignment?" — Is it automatic when the order is confirmed, or when the food is nearly ready? Assigning too early wastes driver time; too late delays delivery. We assign during the Preparing state.
• "What happens if no delivery partner is available?" — Does the order wait? Get cancelled? Get re-queued? This reveals capacity-planning thinking.
• "How is delivery fee calculated?" — Fixed fee, distance-based, or surge-priced? We use a simplified flat fee, but mentioning the alternatives impresses.

These questions demonstrate that you understand the domain, not just the code.