Three times the orders, same hardware
The problem
A growing platform was losing orders at peak. Every incoming order ran two counting queries against a table that kept growing, so the system got slower exactly when it was busiest.
What we did
Profiled the order path end to end, removed the two blocking counts, and added a capacity measurement so the ceiling is now known rather than guessed.
Result
Throughput went from 1.0 to 3.0 orders per second.
How it was measured
Throughput was read from the live order path rather than from a staging copy: orders were pushed through the real pipeline at a sustained rate until the completion rate stopped rising, before the change and again after it, on the same hardware and with the same data volume. The two blocking counts were found by profiling a single request end to end rather than by reading the code and guessing, which matters because both queries looked cheap and only became expensive as the table grew.