Getting Ready: Restaurant Management

There are over 1 million restaurants in the United States alone, and nearly every one of them relies on software to manage tables, orders, and kitchen workflows. Companies like Toast (processing over $100B in annual gross payment volume), Square for Restaurants, Lightspeed, and Oracle MICROS (powering chains like Hilton and Marriott dining venues) all build restaurant management systems at their core.

What makes this problem compelling from a design perspective is that it's a multi-stakeholder real-time system. A host seats guests. A waiter takes orders. A chef prepares food. A cashier processes payment. All of these actors operate concurrently on shared state — the table's status, the order's progress, the kitchen's queue. Designing a system where these actors interact without stepping on each other requires careful separation of concerns and well-chosen design patterns.

Interviewers love this problem because it tests three patterns simultaneously: State (table lifecycle), Command (order operations), and Observer (kitchen display notifications). Most candidates can sketch a basic class diagram, but few can explain how these three patterns interact to form a cohesive system. That's what separates a surface-level answer from a strong one.

By the end of this design problem, you will be able to:

• Model two coupled state machines — Table status and Order status have distinct lifecycles that influence each other
• Apply the State Pattern to manage table transitions (Available → Occupied → BeingCleaned → Available) without if/else branching
• Apply the Command Pattern to encapsulate order operations (place, modify, cancel) as first-class objects that can be queued and undone
• Apply the Observer Pattern to build a Kitchen Display System that reacts to order events in real time
• Design a class hierarchy with ~20 classes spanning tables, orders, menu items, billing, and staff roles
• Write complete implementations in both Python and Java
• Trace a full order lifecycle — from a guest being seated through food preparation to bill payment — as a UML sequence diagram
• Handle restaurant-specific edge cases like modifying orders after kitchen starts preparation, splitting bills, and walk-in vs. reservation seating

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition and Association (Fundamentals S4). The restaurant has tables, tables have orders, orders have items — you need to know when to use composition vs. association.
• State Pattern — how objects change behavior based on internal state (Fundamentals S12). Tables cycle through 4 states, and each state determines what actions are valid.
• Command Pattern — encapsulating operations as objects (Fundamentals S12). Order operations become command objects that flow through the system.
• Observer Pattern — notifying dependents of state changes (Fundamentals S12). The Kitchen Display System subscribes to order events.
• UML Class and State Machine Diagrams — how to model structure and behavior visually (Fundamentals S5).

Recommended prior problems:

• DP6: Vending Machine — uses the same State Pattern for machine states (4 states vs. our 4 table states)
• DP25: Food Delivery Service — similar order lifecycle state machine, but with delivery logistics instead of in-restaurant flow
• DP14: Hotel Management — uses State Pattern for room status, which is analogous to table status

We will design: The core domain logic for a single-location restaurant — table management with state transitions, order creation and lifecycle, menu and order item modeling, kitchen display notification, billing and payment, and staff role modeling.

We will NOT design: Database schemas, REST APIs, real-time websockets, multi-location management, inventory/supply chain tracking, employee scheduling, customer loyalty programs, or third-party delivery integration. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Difficulty: Hard — This problem involves ~20 classes, 3 design patterns working together, two coupled state machines, and a real-time notification subsystem. It's harder than a standalone state machine (like DP6 Vending Machine) because the state of one entity (Table) directly affects the lifecycle of another (Order).

Before we design classes and relationships, let's trace the physical workflow of a sit-down restaurant:

1. Guest arrives. Either with a reservation or as a walk-in. The host checks table availability.
2. Host seats the guest. The table transitions from Available (or Reserved) to Occupied. This is the trigger that starts the ordering process.
3. Waiter approaches the table. The waiter takes the guest's order — a collection of menu items, each potentially with special instructions ("no onions", "extra sauce").
4. Order is placed. The waiter enters the order into the POS system. The order appears on the Kitchen Display System (KDS) — a screen in the kitchen showing all pending orders, ordered by time. This replaced paper ticket rails in most modern restaurants.
5. Chef prepares the food. The chef works through orders on the KDS. As each order's items are finished, the chef marks the order as Ready.
6. Kitchen notifies the waiter. The KDS alerts the assigned waiter (often via a buzz or screen notification) that the order is ready to be served.
7. Waiter serves the food. The order status changes from Ready to Served. The guest eats.
8. Guest requests the bill. The waiter generates a bill from the order — subtotal, tax, and optional tip. The guest may request a split bill (by item or equal split).
9. Payment is processed. Cash, credit card, or debit card. Once paid, the order is Completed.
10. Guest leaves. The table transitions to BeingCleaned. A busser or waiter clears and sanitizes the table.
11. Table is reset. Once cleaned, the table transitions back to Available, ready for the next guest.

Notice how two state machines run in parallel: the table's status (Available → Occupied → BeingCleaned → Available) and the order's status (Placed → InPreparation → Ready → Served → Completed). They're linked — a table can't become Available until its order is Completed — but they have independent transitions. This coupling is the central design challenge.