Awaited in the order it was written
The price watch read its rows, then counted them, because that is the order the lines were typed. Nothing needed the rows first. One wait became none.
The price watch is the report that shows a kitchen every ingredient whose cost moved in the last month: the old price, the new one, the percentage, which supplier. It was on our speed board one afternoon with three loads just under a second each. The route behind it is simple. It reads the newest five hundred changes, and because five hundred is a cap, it also counts how many changes there really were so the screen can say when it has been capped.
That second query exists because of an earlier lesson: a limit on the query that a total is computed from gives you a total that is quietly wrong. So the count was added, and it was added as the next line after the rows. First wait for the rows, then wait for the count, then answer. Two round trips where one would do, for no reason except that one line was written under the other.
The order of the lines is not the order of the work
Neither query needed the other. The count binds the same filter as the rows and nothing from their result. In the fixed route the two are launched together and awaited together, so the database is answering both while the worker waits once. The screen gets the same rows, the same total and the same capped flag, and the test that already pins the percentages and the capped behaviour still passes, now alongside a new one that asserts the two queries were launched together: the second one starts while the first is still in flight.
The demand sheet, which was on the board beside it, had the same fault in a different costume. It read the whole venue row first, every column, then made its four reads: twelve weeks of orders by day, the dishes sold, the ingredient lines, every active product with stock and open orders. All four bind nothing but the venue's id, which the front door had already resolved before the route ran. The venue row is now read alongside them, as two columns, for the name on the answer.
What one wait costs
Beside the database, each removed wait is ten milliseconds and you would not see it. From a worker in London talking to a database in Virginia it is ninety on a normal afternoon, and on the afternoon these two came up the same hop was costing two to four hundred. Our harness is built so the shape is what gets measured: every call costs a fixed twenty-five milliseconds, calls that overlap count once, and the route is pinned at a number of serial steps. Both of these are at two, the door and one wave, and both counted three on the old code.
The demand sheet has a bigger problem waiting behind this one. Our busiest venue's sheet carries five hundred and sixty product lines, and each line asks the database separately what is on order. That is not a waiting problem, it is a width problem, and it is the next thing about that route if the board keeps naming it. One job at a time.