Could this actually run a hundred restaurants?
I asked a capacity question. The useful answer was a map of the order path’s weak points.
A guest flow can work in a demo without being a system I would trust during service. I asked whether Vividish could handle a hundred restaurants ordering every minute.
The answer was not an adoption milestone or a benchmark result. It was a candid review of what happened during an order and which assumptions would become dangerous under concurrent use.
See the original requestInside the screen
One visible tap can hide repeated work.
The quantity control gives me a concrete action to follow through the implementation review. The screen itself cannot answer a capacity question.
Select a detail
Increasing a quantity is easy for a guest. I would trace how many reads and recalculations that action triggers, then inspect whether unchanged menu data is fetched again.
The total is one visible consequence. A capacity review has to connect that update to the data work behind it, while preserving correctness when the cart changes quickly.
Development cart fixture. No restaurant count, latency, query count, or load result can be inferred from this image.
The original request25 Apr 2026 · excerpt
Honest question: can this app run 100 restaurants with menu ordering every minute?
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
One tap was hiding several trips to the database.
The useful move in the AI review was to follow an order through the code instead of starting with a reassuring capacity estimate. A guest can change the cart several times before submitting it. If each change asks the server to assemble expensive context again, the workload starts before the final button. The whole menu graph does not become cheaper just because it is fetched behind a small quantity control.
This changed the question I needed answered. I wanted to know which information was stable for a published menu, which was specific to the table, and which had to be checked again when an order was accepted. Caching everything would be a careless answer. Rebuilding everything for every small change was costly in a different way. The review made those boundaries concrete enough to investigate.
02
The interesting failures were at the boundaries
Order number generation used the current maximum plus one without the scoping and locking needed for concurrent inserts. Two requests could arrive at the same answer.
The order and its items were also inserted through separate calls. If the first succeeded and the second failed, the system could hold an incomplete order. These are correctness problems as much as performance problems.
03
Correctness is part of the busy evening.
The numbering race is easy to picture. Two orders arrive close together, both read the same largest number, and both try to use the next one. A faster interface cannot resolve that conflict. Likewise, a saved order header without its items leaves the restaurant with a record that does not describe what the guest ordered. These are failures people would experience as uncertainty at the table or confusion in the kitchen.
The proposed next work was a transaction around related writes, a properly scoped counter, and protection against repeated submissions. The load test plan then had something meaningful to measure: accepted orders, complete item sets, unique numbering, and response time under simultaneous requests. One hundred restaurants placing an order each minute was the scenario I asked about. It was never evidence of one hundred customers or a successful benchmark.
Capacity is also about correctness when actions overlap. I return to that question in A reservation rule has to survive the final click.
Where this chapter landed
What changed.
The architecture review identified repeated reads, numbering races, and partial write risks. It did not certify capacity or report real restaurant adoption.
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.
Keep one order complete
PostgreSQL describes transactions as a way to make several steps succeed or fail together. That is the relevant foundation for the review’s separate order and item writes. It does not by itself fix numbering, retries, or capacity.