The gate was one hop, and it still read as three
The way in cost up to 73% of server time on six screens, in steps that read like one, two or three database hops. Measured three ways, it was always one.
Every authenticated call pays a toll on the way in: the server checks the session and the venue before the route runs, and we print that cost on the speed board as its own column. The first morning with enough warm loads to read it, the way in was most of the server time on most office screens. 73 percent on the till's transactions list, 62 on reports, around half on the rest. The figures sat in two clusters, near 100 milliseconds and near 210 to 330. A database hop from London to the east coast is about 90 milliseconds. One hop on the cheap screens, two or three on the dear ones. The obvious job was to go and remove a wait.
Three measurements, and the first one killed the idea
We drove the server against a database where every call costs a fixed delay and read the server's own timing header rather than a new instrument. The way in is one hop deep on every route. The venue read had been moved alongside the session read weeks ago, and the timings overlap exactly as they should.
Then on the live site, the same route called in series: 82 milliseconds the first time, then 10, 11, 14, 14. One cold worker and four warm ones. Then twelve copies of that same call at once: 13, 13, 28, 37, 39, 67, 69, 75, 84, 94, 96, 111. Same route, same account, same one hop of work, eight times the serial figure at the top end.
What the column was really measuring
The gate figure was not a measure of the gate. It was a measure of how many requests the screen fired at once, times whether the worker was warm. A screen that fires one call pays one hop. A screen that fires seven pays for seven gates queuing on one worker. Sitting in a column titled as the way in, that reads exactly like the way in being slow, and a morning spent on it would have gone on optimising a single database read that was already as short as it can be.
Our own first hypothesis was wrong twice. We expected serial depth and found one. We then asserted contention, and the local harness could not show it, because it models latency with a timer and parallel calls do not queue there. So the claim was taken to the live site instead of written down as a reason. A reason is a claim, and this one needed the measurement.
What shipped is the number that is actionable: how many API calls the screen fired, counted in the same walk that picks the slowest one, printed beside the gate so the two are read together. Minutes after the deploy, real browsers said it better than the twelve curls did. Every screen firing a single call sat on the 100 millisecond floor. The gate then climbed with the count. The lever is fewer calls per screen, not a faster door, and the hover over the column carries all three measurements so nobody re-derives them.