Design Online Food Delivery Service like Swiggy
Design an Online Food Delivery Service that allows users to browse restaurants, place orders, track deliveries, and supports restaurant and delivery partner management.
An Online Food Delivery Service is a digital platform that connects users with nearby restaurants, allowing them to browse menus, place food orders, and have meals delivered to their doorstep by delivery partners.
The platform acts as a bridge between customers, restaurants, and delivery agents, coordinating everything from order placement to payment processing and delivery logistics.
In this chapter, we will explore the low-level design of a simplified food delivery service.
Let's start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions, clarify ambiguities, and define the system's scope more precisely.
Here is an example of how a conversation between the candidate and the interviewer might unfold:
Candidate: Should the system allow adding new restaurants and updating their menus?
Interviewer: Yes, the system should be able to onboard new restaurants and add new menu items.
Candidate: Should users be able to search for restaurants by location?
Interviewer: Yes, users should be able to search by city, menu keywords, and proximity. A simple string-based or distance-based search is sufficient for now.
Candidate: How should delivery assignment work? Should we auto-assign based on availability and proximity?
Interviewer: Yes, delivery agents should be auto-assigned based on availability and the combined proximity from agent to restaurant and from restaurant to customer.
Candidate: Do we need to support order cancellation? If yes, under what conditions?
Interviewer: Yes, users can cancel orders, but only if the order status is still "PENDING." Once the restaurant has started preparing, cancellations should not be allowed.
Candidate: Should the system notify customers, restaurants, or delivery agents when the order status changes?
Interviewer: Yes, all relevant parties should be notified whenever the order status is updated.
Candidate: Do we need to support payments as part of this design?
Interviewer: You can skip payments for this design. Assume payment is handled automatically when the order is placed.
After gathering the details, we can summarize the key system requirements.
1.1 Functional Requirements
- Support registration of new users, delivery agents and restaurants.
- Support adding restaurants and menu items.
- Allow customers to search for restaurants based on city, menu or location.
- Allow customers to place orders containing multiple items from a selected restaurant.
- Notify restaurants of new incoming orders and allow them to update the order status.
- Auto-assign delivery agents based on availability and proximity
- Notify relevant parties when the order status changes.
- Maintain order history for customers.
1.2 Non-Functional Requirements
- Modularity: The system should be designed with clear separation of components.
- Extensibility: The design should be flexible enough to support future features.
- Maintainability: Code should follow object-oriented principles and be easy to test, debug, and evolve.
After the requirements are clear, lets identify the core entities and their responsibilities within the system.