A service is slow and the team disagrees about the cause. What method identifies the actual bottleneck rather than the suspected one?

The method

Measure where time goes before hypothesising why. Break a request into phases and attribute time to each: queue wait, connection acquisition, each downstream call, local computation, serialisation. Most disagreements dissolve when the breakdown exists, because they were disagreements about which of several plausible causes dominated.

Then, for the phase that dominates:

• Check whether it is queueing or service. High latency with low service time means waiting for a resource, which is a capacity or concurrency-limit problem rather than a code problem.
• Check whether it scales. Add capacity to the suspected bottleneck and observe. If throughput does not improve, it was not the bottleneck — this is the definitive test and it is cheap.
• Check the distribution, not the mean. A bimodal distribution usually means two code paths, and the investigation is about which requests take the slow one rather than about making the slow one faster.

The specific traps

• Optimising what is easy to measure rather than what dominates. Application code is easy to profile; queueing at a connection pool is not, and the second is more often the answer.
• Assuming the last change caused it. Frequently true, and frequently a coincidence with a load threshold that was crossed independently.
• Fixing the reported symptom. The database being slow may be caused by an application change that quadrupled query count, and the fix is in the application.
• Stopping at the first bottleneck. Removing one reveals the next, and capacity planning must anticipate the sequence rather than treating each as a surprise.

The scaling model worth knowing

Throughput does not scale linearly with capacity, and beyond a point it decreases — because of contention for shared resources and the cost of coordination between them. That means there is a capacity level beyond which adding resources makes the system slower, which is deeply counter-intuitive and is regularly observed in practice as "we added instances and it got worse".

The usual cause is a shared downstream: more instances means more connections, more contention, and less throughput per connection.

The organisational point

The disagreement is usually about measurement, not about opinion. A team that cannot attribute latency to phases will argue indefinitely, and a team that can will stop arguing within an hour. Building that attribution is a higher-leverage investment than any individual optimisation.