Server
Vertical scaling
Vertical scaling is handling more load by moving to a bigger single machine, with more CPU, RAM or faster disk. The architecture stays the same.
How it is measured
Compare before and after on the same workload: requests per second at a fixed p95, plus CPU, memory and disk figures. A resize from 2 to 4 vCPU should lift CPU-bound throughput by almost 2x. If it does not, the limit is elsewhere.
Note the downtime for the resize (often a reboot of a minute or more) and the price step, since cloud sizes usually double in cost as they double in size.
Worked example
A Magento store on a 4 vCPU, 8 GB VM hits 100 percent CPU during a weekly sale. The team resizes to 8 vCPU, 16 GB over a 6 minute maintenance window. Capacity rises from 140 to 255 requests per second, and monthly cost goes from 70 to 140 dollars.
The following sale shows MySQL, now on the same box, using the new memory for its buffer pool and the site stays at 55 percent CPU. The next jump would need a different design, since the largest instance is only 4x bigger.
How it differs
Vertical scaling makes one machine larger. Horizontal scaling adds more machines. Vertical excludes the need for a stateless app and a balancer, and horizontal excludes the hard ceiling of the biggest box. Vertical keeps a single point of failure, horizontal introduces coordination. Many sites start vertical because it takes no code changes.
Common errors
Resizing without checking whether CPU, memory or disk was the limit. Forgetting the downtime. Assuming double the size gives double the speed for single-threaded code. Hitting the largest instance type with no plan. Ignoring that the database is on the same box.
In practice
Identify the saturated resource first, resize for that, and measure afterwards. If you are already on a large size, plan the step toward multiple copies before you need it.