Zero diff lines before a byte shipped
A speed change to eight routes should alter nothing a screen receives. We captured every answer before and after on one seed and compared them byte for byte.
Most of what we change for speed is reordering. A route that waited for one read before starting another now starts both together. A helper that looked something up now finds it inside the statement that needed it. None of that should change what the screen receives. The whole point is that it does not. But should not and does not are different claims, and only one of them can be tested.
The capture
Before touching eight venue-settings routes, we seeded a small local database with a few venues: one in a food hall that had locked the theme, one with no hall at all, and one id that does not exist. Then we called every one of the eight routes for each of the three venues, twenty-four calls, and saved every response body to a file. Then we made the change and did it again.
The comparison is a plain diff of the two directories. Zero lines of difference. The same number of bytes on each side. For the kitchen policy and prep-areas routes the next day, six calls, 25,872 bytes each side, zero lines.
Why a seed and not production
Production has real venues and would make a convincing before and after. It is also live, and a comparison that depends on nobody saving a setting in the thirty seconds between captures is a comparison that fails for reasons that have nothing to do with the code. A seed is the same every time. The hall that locked a value locks it on both runs. The missing venue is missing on both runs. If a byte differs, the change did it.
The seed also lets you aim. We put a venue with no hall in deliberately, because two of the eight routes now find the hall by a subquery instead of by reading the venue row first, and a venue with no hall is the case where that could plausibly return something different. It returned the same null it always had.
What the diff does not prove
It proves the answer is unchanged for the three venues in the seed. It does not prove the routes are faster from a customer's browser, which is a separate measurement on a separate machine, and it does not prove the answer is unchanged for a shape of venue nobody put in the seed. Both of those are written down beside the result rather than quietly assumed into it.
What it buys is confidence of a specific kind. A change made for speed is a change made with no feature to point at and say it works. The diff is the thing you point at. Eight routes, twenty-four answers, nothing moved. Ship it.