Restaurant Management System
Design a restaurant system — table setup, menu management, filtered browsing, billing with payment surcharges, and a kitchen order workflow — Zomato / Swiggy style.
Design a system for managing a restaurant, covering table setup, menu management, customer ordering with filters, and billing across multiple payment methods.
This one tests whether you can model a multi-actor workflow cleanly — admin, customer, and (in the bonus) kitchen staff all acting on shared state like tables, menu items, and orders — while keeping billing logic (taxes, payment surcharges) decoupled from the ordering flow itself.
Objective
The primary objective of this project is to design and implement a restaurant management system where admins configure tables and the menu, customers browse and place orders with filtering support, and the system calculates an accurate bill — including taxes and payment-method surcharges — across cash, card, and online payment.
Functional Requirements
Requirements are split into two tiers so you know what to prioritize under time pressure: build first, and build if time allows.
Part 1 — Basic Requirements
Core functionality you must build and get working first.
1. Table Management
The restaurant admin can define and manage the number of tables in the restaurant.
2. Menu Management
The admin can add, update, or remove items from the menu at any time.
3. Customer Ordering & Filtering
4. Billing & Payment
Part 2 — Bonus Features
Extensibility checks — can your design support a kitchen-facing workflow and evolving orders without a rewrite of the core ordering and billing logic.
Example Usage: Full Walkthrough
The source problem doesn't specify an exact command syntax, so here's one reasonable walkthrough exercising setup, filtered browsing, ordering, and billing.
1. Admin sets up tables and the menu
> setTableCount(10)
✅ Restaurant configured with 10 tables.
> addMenuItem("Paneer Tikka", price: 250, veg: true, category: "starter")
> addMenuItem("Chicken Biryani", price: 400, veg: false, category: "main course")
> addMenuItem("Gulab Jamun", price: 120, veg: true, category: "dessert")
✅ 3 menu items added.
2. Customer filters the menu
> browseMenu(filter: { veg: true })
🍽 Veg items:
- Paneer Tikka ₹250 starter
- Gulab Jamun ₹120 dessert
3. Customer places an order at a table
> placeOrder(tableId: 4, items: [
{ item: "Paneer Tikka", qty: 2 },
{ item: "Gulab Jamun", qty: 1 },
])
✅ Order #501 placed for table 4. Subtotal: ₹620.
4. More items are added to the same table before it's billed (bonus)
> addItemsToTable(tableId: 4, items: [
{ item: "Chicken Biryani", qty: 1 },
])
✅ Order #502 added to table 4. Combined subtotal: ₹1020.
5. Kitchen marks the order as ready (bonus)
> kitchenMarkPrepared(orderId: 501)
✅ Order #501 marked as prepared. Wait-staff notified.
6. Bill is calculated and paid
> generateBill(tableId: 4)
🧾 Table 4 bill:
Subtotal: ₹1020.00
Tax (5%): ₹51.00
Total: ₹1071.00
> payBill(tableId: 4, method: "card")
💳 Card surcharge (2%): ₹21.42
✅ Final amount charged: ₹1092.42. Table 4 closed.
Table 4 accumulates two separate orders before billing, the kitchen workflow marks the first order ready independently of billing, and the final bill correctly layers tax on the combined subtotal, then a card surcharge on top of that — showing all four core areas (tables, menu, ordering, billing) working together.