Start it first, take it last
A card settlement route waited four times. One of the waits was for a vault that depends on nothing. Our first fix put it in the wrong wave and kept it slow.
The card settlement screen in the back office shows the platform owner every active venue with its last thirty days of card takings. Its route was doing four things in a line: list the active venues, then make four reads bound to that list, then open the vault that holds the card-provider credentials, then answer. Each of those waits is a round trip to the database, and from a London worker a round trip is about ninety milliseconds on an ordinary day and was four hundred on the morning this came up.
The vault read is the interesting one. It is keyed on nothing. It does not care which venues are active or what they took. It could start at the very top of the route and be collected at the very bottom, and nothing in between would notice.
The fix that kept it slow
Our first attempt put the vault read into the same wave as the venue list, on the reasoning that two independent reads belong together. That is true, and it still serialised things, because the four takings reads needed the venue list and so had to wait for the whole wave, vault included, before they could start. The vault had moved from the end of the line to the beginning of it. The line was the same length.
The counting harness said so immediately. We run these routes against a real database behind a face that charges twenty-five milliseconds per call and records whether each call started while another was in flight. A call that starts with nothing in flight is a step. The first fix counted four steps, same as before.
Start it first, take it last
The shape that works is to start the vault read before anything else and not wait for it until the answer is being assembled. In between, the venue list stopped being a separate read at all: the four takings queries carry it as a subquery, active venues only, so the owner's case is one wave. An account restricted to some venues still reads its own list first and then the wave, two steps where there were four.
Both shapes are pinned: the owner at two serial steps, a fenced account at three, the vault started before the wave and awaited after it. And the answer is checked, not just counted: every active venue present, the thirty-day takings right, the flag that says whether the money can reach the owner's payment account carrying the sentence that explains why not.
The lesson is not about vaults. Any read that depends on nothing should be started at the top and collected at the bottom, and putting it in a wave with something the next wave needs is the same as leaving it in series. The harness counts; the reasoning does not.