Problem and Scope
Design a food-delivery marketplace for customers, restaurants, and couriers. Customers should be able to discover nearby restaurants, place an order, and follow its progress until delivery. Restaurants need to accept and prepare orders, while couriers need suitable work assigned as conditions change in real time. The platform operates across many cities and must remain usable when traffic spikes or one participant becomes temporarily unreachable. Clarify the initial scope, then walk through your design.
Treat the order lifecycle as the central product journey. Decide what the first version includes, define the important state transitions, and make the behavior clear when a restaurant or courier cannot continue.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Allow restaurants to add and update their profiles, menus, and pricing
- Enable customers to search for restaurants based on location, delivery time, and cuisine type
- Let customers view restaurant menus and place orders
- Implement a system to assign delivery drivers to orders
- Allow users to track order status in real-time
- Support payment processing for orders
- Provide notifications to all parties (customers, restaurants, drivers) at different stages of the order
Non-functional requirements:
- High availability: The system should be highly available as it impacts multiple businesses
- Low latency: Restaurant searches and menu loading should be fast (< 150-400ms)
- Scalability: The system should support millions of users, thousands of restaurants, and concurrent orders
- Reliability: Order and payment information should never be lost
- Security: Secure handling of payment information and user data
- Eventual consistency: Updates to restaurant information can be eventually consistent
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- Support approximately 1 million restaurants globally with 100 new restaurants being added daily
- Handle approximately 100 million customers with 10,000 new customers joining daily
- Process millions of searches and views per day
- Support restaurant menus with multiple items and images
- Handle peak ordering times during lunch and dinner hours
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- User service (for customers, restaurant managers, and delivery drivers)
- Restaurant service (for managing restaurant profiles and menus)
- Search service (for finding restaurants based on various criteria)
- Order service (for processing and tracking orders)
- Delivery service (for managing driver assignments and delivery logistics)
- Payment service (for handling transactions)
- Notification service (for sending updates to all parties)
- Image storage and processing service
- Efficiently finding nearby restaurants based on location
- Calculating accurate delivery times based on distance, traffic, and restaurant preparation times
- Handling high traffic during peak hours
- Managing real-time tracking of deliveries
- Ensuring data consistency across distributed systems
- Optimizing the assignment of delivery drivers to orders
- Supporting different payment methods and currencies
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would you handle the geolocation aspect of restaurant searches?
- Focus: Assess the candidate's answer to "How would you handle the geolocation aspect of restaurant searches" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What approach would you take to calculate and display accurate delivery times?
- Focus: Assess the candidate's answer to "What approach would you take to calculate and display accurate delivery times" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system scale during peak ordering hours?
- Focus: Assess the candidate's answer to "How would your system scale during peak ordering hours" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs did you consider when choosing your data storage solutions?
- Focus: Assess the candidate's answer to "What trade-offs did you consider when choosing your data storage solutions" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your design handle a situation where a delivery driver is unavailable or cancels?
- Focus: Assess the candidate's answer to "How would your design handle a situation where a delivery driver is unavailable or cancels" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- Can you explain how your image storage and delivery solution would work?
- Focus: Assess the candidate's answer to "Can you explain how your image storage and delivery solution would work" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Allow restaurants to add and update their profiles, menus, and pricing; Enable customers to search for restaurants based on location, delivery time, and cuisine type; Let customers view restaurant menus and place orders. Establishes the constraints that materially affect Design Food Delivery System, including High availability: The system should be highly available as it impacts multiple businesses; Low latency: Restaurant searches and menu loading should be fast (< 150-400ms). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering User service (for customers, restaurant managers, and delivery drivers); Restaurant service (for managing restaurant profiles and menus); Search service (for finding restaurants based on various criteria); Order service (for processing and tracking orders). Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as Support approximately 1 million restaurants globally with 100 new restaurants being added daily; Handle approximately 100 million customers with 10,000 new customers joining daily to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Search service (for finding restaurants based on various criteria); Image storage and processing service; Ensuring data consistency across distributed systems. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Ensuring data consistency across distributed systems; High availability: The system should be highly available as it impacts multiple businesses; Reliability: Order and payment information should never be lost. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Ensuring data consistency across distributed systems; Optimizing the assignment of delivery drivers to orders; Supporting different payment methods and currencies. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.