Measure before you scale

The performance fundamentals lesson said it once; at scale it's worth saying louder: measure before you change anything. Scaling and optimisation are expensive and intuition is unreliable — the slow part is almost never where you'd guess. Data tells you where to spend effort; everywhere else is wasted work.

Profile, don't guess

A profiler measures where a program actually spends its time and memory. Under load, the same logic applies to the whole system: which endpoint is slow, which query dominates, where requests pile up. Look at real numbers — latency percentiles, throughput, resource use — not anecdotes.

Pay attention to tail latency (p95, p99), not just the average. An average of 100ms can hide that 1% of users wait five seconds — and at scale that 1% is a lot of unhappy people.

Find the one bottleneck

Performance follows a brutal rule: a system is only as fast as its slowest required step. A tiny fraction of the code usually accounts for most of the cost. Find that bottleneck and fix it; optimising anything else is invisible to the user.

And often the biggest win is algorithmic, not infrastructural — the O(n²) loop or the missing database index (the complexity and data-structures lessons) beats throwing servers at the problem. Always check whether you have a code problem before you have a scaling problem.

Know your target

Optimisation has no natural end, so define one. Tie it to the SLOs from the monitoring lesson — "p99 under 300ms at 1,000 requests/second." With a target you know when to stop; without one you'll polish forever, adding complexity for gains no user notices.

Where to go next

Once you know what's slow and that the code is sound, you scale. Next: scaling strategies.