A reservation rule has to survive the final click.
A fast availability check is only one part of a dependable booking flow.
The reservation work needed more than a reassuring demo. I asked for a review at a much larger restaurant scale, including the guardrails that decide whether a booking is allowed.
The response separated two questions that are easy to combine: were the rules scoped and efficient, and was the whole host stand experience ready for busy use? The answers were not identical.
See the original requestInside the screen
An offered time is not a saved booking.
The editor separates choosing a time from committing the change. That distinction matters when availability can change between the two.
Select a detail
The available times show what the interface currently offers. I still need validation at the final save, because another booking could change capacity after this view was rendered.
The sentence above the action says the booking stays unchanged until saving. That gives the person a useful boundary while trying another time.
Save changes is the point where the rule has to survive. The relevant evidence is the server behaviour and error recovery, not merely the button being present.
Actual reservation component rendered with a local fixture. It does not exercise concurrent bookings or prove server enforcement.
The original request13 May 2026 · excerpt
see what was built and will it scale when there are 1000 restaurants and hundreds of reservations being made
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
Availability is a promise that can expire while you type.
A person can select a slot, read the form, and spend a minute entering details. During that minute another booking can arrive. That is the ordinary situation behind the server check. The browser can explain availability, but the submission has to evaluate the current state before accepting the reservation. I wanted the review to follow that promise all the way to the write.
The venue and day boundary of the public assignment lock was a meaningful detail. Two requests competing for the same local capacity need coordination. An unrelated restaurant on another date should not wait behind that decision. Asking the AI to trace the scope of the lock gave me a more useful answer than asking whether the reservation code looked scalable in general.
02
Concurrency belongs in the booking model
The public table assignment path used a transaction and a lock scoped to a venue and day. That is a narrower coordination boundary than blocking unrelated restaurants or all dates together.
The record also contained focused timing probes. They were useful engineering evidence about particular functions, not a simulation of every condition in a thousand real restaurants. I do not turn them into a broad capacity claim here.
03
The staff route was where the story became less comfortable.
The review found gaps on the staff side that a clean public booking form would not reveal. Required contact information could be presented as optional, and creation did not have the same overlap and table size protection as the stronger public path. Some policy failures also needed more specific messages. These are practical problems for someone entering a booking while another guest is waiting.
I would turn that review into a sequence of ordinary scenarios: attempt a conflicting table, omit the required contact detail, and try a date restricted by policy. The useful outcome is not merely a rejected request. It is a rejection the staff member can understand and recover from without losing their work. The recorded timing probes examined small functions. They did not settle those interactions or simulate a thousand complete restaurants.
A single happy path is not a capacity review. I return to that question in Could this actually run a hundred restaurants?
Where this chapter landed
What changed.
The review supported the scoped public guardrails while identifying remaining staff flow and conflict safety work. It did not certify the complete reservation product at the hypothetical scale.
Added while revisiting this story · September 2026
The thinking behind the detail.
Research notes to take these decisions further. These sources were reviewed for this retrospective.
Coordinate the competing requests
PostgreSQL advisory locks let an application choose a coordination key. Their usefulness depends on the application consistently taking the appropriate lock. That helps explain why the venue and day scope matters in this review.