Restaurant, Menu, Order classes in LLD - System Design Exercise

Design: Restaurant Ordering System

Design classes and their relationships for restaurant, menu, and order management. Exclude payment processing and delivery logistics.

Functional Requirements

FR1: Allow creation and management of restaurants

FR2: Each restaurant has a menu with multiple items

FR3: Customers can place orders selecting items from the menu

FR4: Track order status (e.g., placed, preparing, served)

FR5: Support multiple orders per restaurant

Non-Functional Requirements

NFR1: Support up to 100 restaurants

NFR2: Each restaurant can have up to 200 menu items

NFR3: Handle up to 1000 concurrent orders

NFR4: Order status updates should reflect within 1 second

NFR5: System availability target 99.9%

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Restaurant class to hold restaurant details

Menu class to hold menu items

MenuItem class for individual dishes

Order class to represent customer orders

OrderItem class to represent items within an order

Design Patterns

Composition pattern for Menu containing MenuItems

State pattern for Order status management

Observer pattern if real-time order status updates are needed

Reference Architecture

RestaurantOrderingSystem
  |
  +-- Restaurant
        |
        +-- Menu
              |
              +-- MenuItem
  |
  +-- Order
        |
        +-- OrderItem

Components

Restaurant

Class

Represents a restaurant with details and a menu

Menu

Class

Holds a list of MenuItems for a restaurant

MenuItem

Class

Represents a single dish or item available in the menu

Order

Class

Represents a customer's order with multiple OrderItems and status

OrderItem

Class

Represents a MenuItem selected in an order with quantity

Request Flow

1. Customer views Restaurant and its Menu

2. Customer selects MenuItems and quantities to create an Order

3. Order is created with OrderItems referencing MenuItems

4. Order status is set to 'placed' and saved

5. Kitchen updates Order status as it progresses (preparing, served)

6. Customer or system queries Order status for updates

Database Schema

Entities: - Restaurant(id PK, name, address, phone) - Menu(id PK, restaurant_id FK) - MenuItem(id PK, menu_id FK, name, description, price) - Order(id PK, restaurant_id FK, status, created_at) - OrderItem(id PK, order_id FK, menu_item_id FK, quantity) Relationships: - Restaurant 1:N Menu - Menu 1:N MenuItem - Restaurant 1:N Order - Order 1:N OrderItem - OrderItem N:1 MenuItem

Scaling Discussion

Bottlenecks

Database load with many concurrent orders and menu queries

Order status update latency under high load

Memory usage if all menus and orders are cached in memory

Solutions

Use read replicas and caching (e.g., Redis) for menu data to reduce DB load

Implement asynchronous order status updates with message queues

Paginate order queries and limit in-memory caching to active restaurants/orders

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing classes and relationships, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain clear separation of concerns between Restaurant, Menu, and Order classes

Discuss how composition models real-world relationships

Highlight how order status management supports real-time updates

Mention scaling strategies for read-heavy menu data and write-heavy orders

Show awareness of trade-offs in caching and consistency

Practice

1. Which class should primarily hold the list of available food items and their prices in a restaurant system?

easy

A. Restaurant

B. Menu

C. Order

D. Customer

Solution

1. Step 1: Understand the role of Menu class

   The Menu class is designed to store food items and their prices, acting as the restaurant's catalog.

2. Step 2: Differentiate from other classes

   Order tracks customer requests, Restaurant manages overall operations, Customer represents the diner. Only Menu holds items and prices.

3. Final Answer:

   Menu -> Option B

4. Quick Check:

   Menu = items and prices [OK]

Hint: Menu holds items and prices, not orders or customers [OK]

Common Mistakes:

• Confusing Order with Menu
• Thinking Restaurant holds item prices
• Assuming Customer stores menu data

2. Which of the following is the correct way to add a new item to the Menu class in a typical object-oriented design?

easy

A. menu.addItem('Pizza', 12.99)

B. Menu.add('Pizza', 12.99)

C. menu.insertItem('Pizza', 12.99)

D. addItem(menu, 'Pizza', 12.99)

Solution

1. Step 1: Identify instance method usage

   Adding an item to a Menu instance uses the instance method, so calling menu.addItem(...) is correct.

2. Step 2: Eliminate incorrect syntax

   Menu.add(...) suggests a static method which is unlikely; insertItem is not standard; addItem(menu, ...) is procedural, not OOP style.

3. Final Answer:

   menu.addItem('Pizza', 12.99) -> Option A

4. Quick Check:

   Instance method call = menu.addItem(...) [OK]

Hint: Use instance.method() to add items, not static or procedural calls [OK]

Common Mistakes:

• Using static method call instead of instance method
• Confusing method names
• Calling functions outside class context

3. Given the following code snippet, what will be the total cost of the order?

menu = Menu()
menu.addItem('Burger', 5.0)
menu.addItem('Fries', 2.5)
order = Order(menu)
order.addItem('Burger', 2)
order.addItem('Fries', 3)
total = order.calculateTotal()

medium

A. 17.5

B. 15.0

C. 20.0

D. 12.5

Solution

1. Step 1: Calculate cost for each item

   Burger price is 5.0, quantity 2 -> 5.0 * 2 = 10.0; Fries price is 2.5, quantity 3 -> 2.5 * 3 = 7.5.

2. Step 2: Sum the costs

   Total cost = 10.0 + 7.5 = 17.5.

3. Final Answer:

   17.5 -> Option A

4. Quick Check:

   (5*2)+(2.5*3) = 17.5 [OK]

Hint: Multiply price by quantity, then add all items [OK]

Common Mistakes:

• Adding quantities instead of multiplying by price
• Forgetting to multiply price by quantity
• Mixing up item prices

4. In a system where the Order class adds items without checking the Menu, what is the main issue that can occur?

medium

A. Order will reject all items by default

B. Menu prices will automatically update in Order

C. Order may include items not available in the Menu

D. Restaurant will close automatically

Solution

1. Step 1: Understand the role of validation

   Order should verify items exist in Menu to avoid invalid orders.

2. Step 2: Identify consequence of missing check

   Without checking, Order can contain items not on Menu, causing errors or confusion.

3. Final Answer:

   Order may include items not available in the Menu -> Option C

4. Quick Check:

   Missing validation = invalid items in Order [OK]

Hint: Always check Menu before adding items to Order [OK]

Common Mistakes:

• Assuming automatic price updates
• Thinking Order rejects items by default
• Confusing system behavior with unrelated effects

5. How would you design the Order class to handle multiple orders from different customers simultaneously in a scalable restaurant system?

hard

A. Store all orders in a single list without identifiers

B. Keep orders only in memory without persistence

C. Allow only one order at a time to avoid conflicts

D. Use unique order IDs and store orders in a centralized database with concurrency control

Solution

1. Step 1: Identify need for unique order tracking

   Each order must have a unique ID to distinguish between multiple customers' orders.

2. Step 2: Ensure scalability and data integrity

   Storing orders in a centralized database with concurrency control allows multiple orders simultaneously without conflicts.

3. Final Answer:

   Use unique order IDs and store orders in a centralized database with concurrency control -> Option D

4. Quick Check:

   Unique IDs + concurrency = scalable order handling [OK]

Hint: Use unique IDs and concurrency-safe storage for multiple orders [OK]

Common Mistakes:

• Ignoring concurrency issues
• Using single list causing data overwrite
• Not persisting orders leads to data loss