# Design a Concurrent Restaurant Waitlist and Seating System Design a restaurant system with a configurable set of tables and a FIFO waitlist of parties. Each party has a unique ID, size, arrival sequence, and SMS contact. When a table becomes available, prefer the earliest waiting party whose size exactly equals the table's capacity; if none exists, seat the earliest party that fits. Thus an eight-person party may bypass an earlier two-person party when an eight-seat table opens. The assignment must be safe when parties join concurrently and multiple tables become available at the same time. Once an assignment commits, the system sends the party an SMS notification. Explain classes, data structures, APIs, synchronization, failure handling, and tests; pseudocode is sufficient. ### Constraints & Assumptions - One party can hold at most one active waitlist entry or table assignment. - One table can have at most one active party. - SMS delivery may fail or repeat and must not determine whether the table assignment commits. - Cancellation can race with seating, so define a deterministic winner. ### Clarifying Questions to Ask - May tables be combined, and can a party accept a table smaller than its size? - How long does a party have to confirm after notification? - Does an exact-size preference override FIFO indefinitely, or is aging required? - Is the system in one process or shared by several hosts and service instances? ### What a Strong Answer Covers - Explicit seating policy and stable arrival ordering - Atomic party/table state transitions under concurrency - Data structures that support exact-size preference and FIFO fallback - Reliable, idempotent notification after commit - Cancellation, timeout, fairness, recovery, and race-focused tests ### Follow-up Questions - How would you prevent starvation of small parties? - What if an SMS succeeds but the notifier crashes before recording success? - How can two hosts avoid assigning the same table? - What changes when tables may be combined?