Performance Optimisation

Performance work goes wrong in a predictable way: someone optimises the part of the system that is most interesting to optimise, rather than the part that is slow. Weeks disappear and the p99 does not move.

Measure first

So we measure first, and we measure the thing users experience — end-to-end latency distributions, not averages, under load that resembles production. Averages conceal exactly the problems worth finding.

That usually means profiling under realistic concurrency, examining query plans and index usage rather than trusting the ORM, looking hard at serialisation and network round trips, and checking whether caching is helping or quietly serving stale data.

Then fix

Fixes tend to be unglamorous and effective: an index that was never added, an N+1 query behind an abstraction, a synchronous call that should have been a queue, chatty serialisation, connection pool exhaustion, a cache with a hit rate nobody ever checked.

Having built systems where latency was measured in microseconds and a slow path meant real financial loss, we know which optimisations earn their complexity and which are premature. Not every system needs to be fast — but the ones that do need to be fast in the right places.

What you walk away with

Benchmarks before and after, the reasoning behind each change, and load tests wired into your pipeline so a regression shows up in CI rather than in production. Lower cloud spend is a common by-product: faster code needs fewer instances.