Fix one route, then count its siblings
One venue route checked the row existed, then read it. Two like it were fixed months ago. Counting the family found eight more with the same two waits.
The Venue screen in the back office was the slowest thing on our speed board one morning: five loads, each a second and a half, every one of them warm. The screen fires seven calls at once when it opens, and the slowest of the seven that morning was the one that reads a venue's price adjustments. From beside the database that call answers in twenty-odd milliseconds. From a browser in the UK it was taking a second.
The route was doing two things in a row. First it checked the venue existed. Then it read the adjustments. Both were keyed on nothing but the id in the address. Neither needed the other's answer to start. They ran one after the other anyway, because that is the order the code was written in, and every wait in a row is a trip across the Atlantic for a reader far from the database.
The fix was small. The count was the job
Making the two reads run together is a one-line change. The interesting question was how many other routes in the same file had the same shape. So before touching anything we counted: a short script over the venue-settings file, looking for the pattern of a venue check awaited before a read keyed on the same id.
Eight. Options, idle media, adjustments, clock, theme, tips, notices and charges. Two more in the same family, opening hours and tables, had been fixed exactly this way back in the summer, and the lesson had stopped there. Nobody went looking for the siblings at the time, so six months of venue screens paid a second hop they did not need.
What we shipped
All eight now run the existence check and the read together, and decide the not-found answer once both are back. A venue that does not exist still gets a 404, and nothing about it leaks, because the answer is assembled only after the check has spoken. Two of the eight needed the venue's hall as well, and used to wait for the venue row to say which hall it was in. They now find the hall by a subquery inside the same statement, so a venue with no hall still answers correctly and nobody waits for a row to be read first.
A test harness runs the real worker through its real front door against a counting database, and pins each of the eight at a fixed number of serial steps. The proof is in the count, not in the stopwatch: the stopwatch beside the database barely moves, and the win only shows from where the customer sits.
Why it matters in a food hall
Three of those eight calls sit on the Venue screen that every operator opens to change an opening time or a service charge. Each removed wait is roughly a hundred milliseconds off every load from the UK. None of that is visible from a development machine next to the database, which is the whole reason the siblings went unfixed for so long. When you fix one route for a shape like this, the second half of the job is counting who else has it.