Restaurant management system — order lifecycle and server-side totals

Restaurant systems teach state machines and trust boundaries more clearly than another todo app ever will. An order moves through placed → preparing → served → completed (names may vary by kit). Dine-in tables free when orders finish. Line totals come from menu price lookups on the server — always — because a malicious client can POST total: 1. If you can defend those three ideas with a live demo, you have a viva-ready MERN restaurant project.

Opening pitch (35 seconds)

Our Restaurant Management System supports staff and customer flows on a MERN stack. Customers browse the menu and place dine-in or takeaway orders; staff advance kitchen status; the system keeps table occupancy in sync for dine-in. Payable amounts are recomputed from menu item IDs and quantities on the server. Role-based views separate kitchen, service, and admin reporting. Inventory ERP and rider GPS are out of scope unless explicitly built.

Scope that survives final year timelines

In scope: menu CRUD, order taking, kitchen queue, table status, billing with tax/service lines if included, daily sales summary. Out of scope by default: delivery fleet tracking, full recipe-level inventory, multi-branch franchise sync, AI demand forecasting. Write the boundary in Chapter 1. Comparing to Swiggy: you are building in-house restaurant operations, not a city-scale marketplace.

Differentiation without fake AI

College logo, realistic Indian menu seed data (prices in INR), optional static QR menu page, PDF bill export. Rank stretch goals: low effort PDF bill; medium QR menu; high WebSocket kitchen — only if time remains. Empty WebSocket buttons are worse than honest polling every 30 seconds.

Order state machine

Define allowed transitions in one table. Example: placed → preparing → served → completed, with cancelled from early states only. Staff roles may advance status; customers get read-only tracking. Server rejects skipped jumps if you enforce linear kitchen flow. Diagram this in Chapter 4 — examiners recognize state machines and often award design marks quickly.

Kitchen workflow nuances

Kitchen view filters to active orders. Mark preparing when cooking starts; served when food leaves kitchen; completed when paid/cleared per your rules. Optional sound on new order is a small customization. Polling is acceptable for college labs; mention WebSockets as future work for true push.

Void and edit rules

Allow item void only before preparing if that is your policy; after preparing, require supervisor role. Document one realistic interruption: waiter voids a wrong item — test case ID in Chapter 6. Panels appreciate business-rule awareness as much as JSX cleanliness.

Table sync for dine-in

Dine-in orders require tableId. On accept/place: table → occupied. On complete/cancel (policy-dependent): table → available. Prevent two active dine-in orders fighting for the same table if that is your invariant. List view of tables is enough; fancy canvas floor plans are optional sugar.

Takeaway vs dine-in

Takeaway omits table or sets null; dine-in requires selection. Test both paths. UI should not show table picker for takeaway. Mixed modes in one demo look polished.

Security story — memorize the total recomputation

Attack: client sends menu prices of ₹0 or a forged grand total. Defense: server loads canonical prices from Menu collection by item ID, multiplies by quantity, adds tax/service per configuration, stores snapshot on the order. Historical orders keep line-item price snapshots so later menu edits do not rewrite yesterday’s bills.

Optional live proof: DevTools edit of POST body fails validation or still bills correct amount. This answer overlaps conceptually with hotel server-side rates — see hotel booking architecture.

Auth and roles

Examples: admin (menu, users, reports), staff/waiter (orders, status, tables), customer (browse, place, track). JWT + requireRole same pattern as Library Management System. Hide admin nav for customers, but never rely on hiding alone.

Bill calculation details

Subtotal = Σ (snapshotPrice × qty). GST example: 5% on subtotal if you include tax — say the percentage is configurable. Service charge optional. Never trust browser-only math for the stored bill. Screenshot a sample bill in results chapter with line items visible.

Embedded order items vs separate collections

Common Mongo approach: order document embeds items[] for atomic reads of a ticket. Tradeoff: item analytics may need aggregation unwinds. Justify your choice in Chapter 4. Indexes: status + createdAt for kitchen queues; tableId + status for occupancy checks.

Reporting for admin

Daily revenue $group, top-selling items, order counts by status. One chart is enough for viva. Seed a day’s worth of completed orders so the chart is not empty on stage. Explain pipeline stages verbally if asked: match → group → sort → limit.

Customer self-service demo value

Show customer placing takeaway; show staff advancing status; show customer tracking page update after refresh/poll. Then show staff placing dine-in for table 4. Two personas prove RBAC better than a single admin god-user demo.

Inventory honesty

Stock deduction per ingredient is a different product (and a different set of failure modes). Many successful submissions keep menu items only. If you did not build inventory, do not imply ERP. Future work bullet is fine.

Extended viva Q&A

Q: Why MongoDB? A: Order documents with embedded items fit ticket-shaped data; flexible menu attributes.
Q: Why not only Excel? A: Concurrent staff, roles, live status, auditability.
Q: UPI payments? A: Future work or pay-at-counter scope — do not half-integrate.
Q: Offline mode? A: Out of scope; requires sync conflict design.
Q: Split bill? A: Advanced; mention as future work unless finished.
Q: Difference from hotel kit? A: Orders/tables/kitchen vs rooms/date intervals; shared auth platform — Hotel Booking System.

Live demo script (five minutes)

1. ▸Admin: add or edit a menu item price.
2. ▸Customer: place takeaway with two items; note server total.
3. ▸Staff kitchen: placed → preparing → served.
4. ▸Staff: dine-in table 4 order; show table occupied.
5. ▸Complete order; table frees; admin daily sales chart.

Literature and comparison angles

Cite one open-source restaurant/POS repo and one limitation (missing RBAC, no GST, etc.). Compare to notebook ordering: digital audit trail, tax calculation, kitchen visibility. Keep claims undergraduate-sized.

Testing table (copy into Chapter 6)

| ID | Case | Expected | | --- | --- | --- | | T1 | Empty cart checkout | Blocked | | T2 | Negative quantity | Rejected | | T3 | Tampered total | Server price wins | | T4 | Skip state jump | 400 if enforced | | T5 | Double-seat same table | Rejected if invariant on | | T6 | Customer hits admin API | 403 |

Report chapter mapping

Chapter 1: problem statement and Swiggy-scope boundary. Chapter 3: actors, dine-in/takeaway use cases. Chapter 4: state machine, ER, price trust boundary. Chapter 5: controllers for order status and totals. Chapter 6: table above. Chapter 7: no inventory, polling not push, payment future work.

Menu modeling details

Fields that matter: name, category (Starters, Mains, Breads, Beverages), price, isAvailable, optional veg/non-veg flag, optional image URL. Soft-disable items (isAvailable: false) instead of deleting historical references. Categories drive customer browse UX. For Indian college demos, seed recognizable dishes with INR prices so faculty instantly understand the screen.

Combos and variants

Half/full portions or size variants complicate line items. If unsupported, reject “variant” questions as future work. Do not invent combo pricing logic on the whiteboard that the code cannot run.

Concurrency in the kitchen

Two waiters updating the same order status: last write wins unless you use version checks. Practical approach: status transitions are monotonic; attempt to set served when already completed fails. Document that. Full OT restaurant concurrency control is unnecessary for marking if you explain monotonic states.

Printing and KOT

Kitchen Order Ticket print (browser print CSS) is a popular stretch. If you have it, demo once. If not, kitchen screen is enough. Avoid claiming thermal printer integration without hardware.

Tax configuration as data

Store GST percent in a settings collection or env config rather than hardcoding magic numbers in five files. Viva answer: “Changing GST is a config update, not a redeploy of business logic scattered everywhere.” Same pattern as hotel tax lines and ecommerce pricing centralization.

Customer UX expectations

Mobile-responsive menu browse helps if the panel tests a phone, but a desktop-first demo is fine when stated. Order tracking page should show timestamps per status change if you store a status history array — strong storytelling (“placed 7:01, preparing 7:04”). Without history, show current status only and list history as enhancement.

Accessibility and language

English UI with optional Hindi labels for buttons is a customization some colleges like. Keep code strings consistent. Do not mix role names across languages in the RBAC matrix.

Ops comparison paragraph for Chapter 1

Manual notebook ordering loses kitchen visibility, makes tax error-prone, and lacks role separation between cashier and kitchen. Your system addresses those three pains. That problem framing beats buzzword openings about “digital India transformation” without specifics.

Sibling kits and shared lessons

Server-side money computation appears in hotel bookings and restaurant bills; RBAC appears in library loans; state machines appear in restaurant orders and fleet trips. Reading vehicle fleet final year guide helps you speak “operations software” vocabulary. Product cross-links: Hotel Booking System and Library Management System.

Whiteboard: place order sequence

Customer POST /orders { items:[{menuItemId, qty}], mode, tableId? } → auth → validate items → lookup prices → compute totals → set status placed → occupy table if dine-in → audit → response. Then PATCH status with requireRole staff.

Waiter and kitchen swimlane

Customer places dine-in → waiter confirms table seating → kitchen sees new ticket → kitchen marks preparing → waiter delivers → marks served → cashier completes payment status → table frees. Even if waiter and cashier are one staff role in code, narrating swimlanes shows you understand restaurant operations. Draw two horizontal lanes on the whiteboard if asked for a collaboration diagram.

Peak-hour story

At peak, polling every 30s may feel slow; WebSockets would push new tickets instantly. Defend polling as deliberate scope for college labs with proxy issues, and list push updates under future work. That tradeoff language sounds senior compared to “we didn’t know WebSockets.”

Menu availability toggles during service

86’ing an item (isAvailable: false) should hide it from customer browse immediately while leaving it on in-flight orders. Staff trying to add an 86’d item to a new order get a 400. Demo this: disable “Paneer Butter Masala,” refresh customer menu, show it gone. Small, vivid, memorable.

Tips and service charge

If you include tips, store separately from GST. If not, say cash tips are offline. Do not mix tip into tax math. Clarity here prevents accounting-style trap questions.

Export and compliance light touch

CSV export of daily orders for the owner’s accountant is a one-endpoint win. Soft-delete users rather than hard-delete if orders reference them. Retain completed orders for the demo dataset rather than wiping history each seed — or provide seed vs seed:demo scripts.

Mapping viva answers to artifacts

State machine → diagram in report. Server totals → code pointer in order.controller. Table sync → test T5. Customer tracking → live UI. When every answer has an artifact, you look prepared rather than scripted.

Run a full dress rehearsal with two browsers (customer + staff) on the presentation machine. Confirm the kitchen view updates after a manual refresh within your polling interval, and confirm the occupied table returns to available only after completion — not after preparing. That single lifecycle pass catches most demo bugs that theory reading misses. Keep INR seed prices and veg badges consistent with what your report screenshots show so examiners do not think you swapped datasets overnight. If the venue blocks MongoDB Atlas IPs, switch the connection string to a local Mongo instance before the panel arrives rather than debugging firewall rules mid-viva.

Common mistakes

Client-side-only totals. Kitchen UI that anyone can open without role checks. Seed menu with USD-only prices for an Indian college demo without reason. Claiming real-time while never refreshing. Floor-plan UI that breaks the demo. Feature list longer than what you can click under five minutes. Deleting menu items that appear on active orders without a soft-disable policy. Showing admin reports before proving a single order lifecycle end-to-end.

Pre-viva checklist

• ▸[ ] Menu seeded in INR with readable names
• ▸[ ] Customer and staff logins work
• ▸[ ] State transitions visible on kitchen view
• ▸[ ] Table occupy/free demonstrated
• ▸[ ] Server total explanation rehearsed
• ▸[ ] Sales chart non-empty
• ▸[ ] 403 path ready
• ▸[ ] Backup video if venue Wi-Fi blocks Atlas

Related reading

See also hotel booking architecture and vehicle fleet final year guide for another operations-style MERN domain.

Project kits

• ▸Restaurant Management System — order lifecycle, table sync, and server-side billing patterns with seed data.
• ▸Hotel Booking System — sibling hospitality kit for architecture comparison in viva.

Takeaway: A defensible restaurant MERN project is a state machine plus server-side pricing plus table occupancy sync — demonstrated with both staff and customer logins under five minutes. The Restaurant kit seeds menu and tables so you can spend viva time on invariants, trust boundaries, and kitchen flow — not on typing sample dishes while the panel waits.