Scaling up and scaling out
Bigger machine or more machines: the first big decision when traffic grows.
Your food-delivery app launches and one server runs everything. Then a promotion lands and the server's CPU sits at 95 percent at dinner time. You have two basic moves. Scaling up (vertical scaling) means moving to a bigger machine: more CPU cores, more memory, faster disks. Scaling out (horizontal scaling) means adding more machines of similar size and sharing the work between them.
Scaling up is wonderfully simple: no code changes, no new moving parts, and every request still talks to one process that has all the data in one place. It has hard limits though. The biggest machine you can buy is finite, prices climb faster than capacity at the top end, you usually need downtime to resize, and one machine is one point of failure. If it crashes at dinner, the whole app is down.
Scaling out has no ceiling in practice and gives you redundancy: if one of five servers dies, four still answer. The price is complexity. Requests must be spread over the machines, the machines must not depend on private local state, and anything shared (like the database) becomes the next bottleneck. This module is mostly about handling that complexity.
A sensible order of operations
Step 1 of 4
Measure first
Find the real bottleneck: CPU, memory, disk, network or the database. Adding web servers does nothing if the database is the slow part.
Your turn
Your single server handles 800 requests per second at 90 percent CPU. Traffic will triple in a month. List the steps you would take and the first thing you would measure.
Stuck? Decide what to check before buying hardware.
What to remember
Scaling up uses a bigger machine: simple, but limited and a single point of failure.
Scaling out adds machines: more capacity and resilience, but needs a balancer and stateless design.
Measure the bottleneck before scaling anything.
The data tier is usually the hardest part to scale out.