Premium preview
Design an OpenTable-style restaurant reservation system where diners book a time slot and party size at a restaurant, restaurants optimize table assignment, and no-shows are handled without requiring...
The requirements are open as a taste. From the numbers onward, the full guide opens in the app.
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
01What is the diner actually promised — a specific table, or a time?
A time slot plus a party size at the restaurant — the specific table is the restaurant’s packing problem, assigned and re-assigned later; decoupling the promise from the table is what keeps the floor flexible.
02Where does availability come from — who defines it?
The restaurant defines a floor plan (tables, capacities, which tables combine) plus a slot grid and turn times; the system derives which party sizes still fit each slot, including combinations like two 2-tops making a 4.
03Can diners cancel or change a booking after making it?
Yes: cancelling frees the capacity immediately, and a party-size change re-runs the fit check — a 2 becoming a 6 may simply not fit the same slot anymore.
04The slot they want is full — then what?
They join a waitlist keyed by party size and time window; when a cancellation frees matching capacity, the system offers the slot automatically instead of leaving it to a lucky refresh.
05Is a credit card required to book?
No by default — most bookings take no payment. Restaurants opt specific cases (large parties, prime Saturday slots) into a card-on-file hold, authorized at booking and charged only on no-show or late cancel, backed by reminders for everyone.
06What does the restaurant side get to do?
A console to edit the floor plan, block tables, mark parties seated or no-show, and override the automatic table assignment — the host always outranks the solver.
Out of scopeIn-restaurant ordering and paying for the meal (POS territory) · Reviews, photos, and ratings content · Delivery and takeout — this is seats, not food logistics
01How fresh does search availability have to be?
Seconds-stale is fine: search reads a derived availability view, and the booking transaction re-checks the truth — a stale search costs a rare “just taken” message, never a double-booking.
02Two parties grab the last fitting slot at once — who wins?
Exactly one wins: the claim is a single row-level transaction against the slot’s remaining capacity for that party size; the loser gets nearby alternatives and a waitlist offer, not a phantom booking.
03How much write contention are we really designing for?
Contention is tiny by flash-sale standards — even peak booking is under one write per restaurant per second — so plain database transactions suffice and the engineering budget goes to assignment quality.
04Table assignments keep reshuffling — can a confirmed booking break?
A confirmed reservation (slot plus party size) is durable and always honored: the solver may move the party between tables until they walk in, but only in re-packings that keep every confirmed booking seatable.
05How reliable do the notifications need to be?
Reminders and waitlist offers are revenue-bearing: a missed reminder raises no-shows and a late offer is an empty table, so notifications get delivery tracking and retries, and reminder timing is tuned against the measured no-show rate.
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.
Locked in the app
Locked in the app
Locked in the app
Locked in the app