The first rule of scaling is to optimise nothing without evidence. We instrument the real system and measure response time by endpoint, expensive queries, connection saturation and queue depth.
In many systems, most of the problem comes from three bottlenecks. Caching absorbs repeated reads, a few indexes or rewritten queries release database pressure, and heavy tasks such as e-mail or media processing move out of the user request.
Only then do we add capacity through read replicas, vertical or horizontal scaling, and a CDN for static resources. These decisions are expensive when made from intuition and straightforward when measurements justify them.
Before the expected peak, we test at twice the target load and observe what fails first. Breaking a controlled environment on Tuesday afternoon is preferable to discovering the limit in production on Monday morning.
The usual outcome is substantially higher traffic on the same software architecture, without server costs following the same curve.
