Vertical vs Horizontal Scaling
You'll learn to
- -Distinguish scaling up from scaling out
- -Explain why horizontal scaling requires statelessness
When your single web server in the logic tier starts struggling under load, you have exactly two directions to go: make that one server bigger, or add more servers next to it. These are vertical and horizontal scaling, and the choice between them shapes almost every architectural decision that follows.
Make your single server bigger - more CPU, more RAM, faster disk.
Imagine you run a one-person tailor shop. Instead of hiring more tailors, you simply work longer hours and buy a faster sewing machine. You're "scaling up" yourself.
Vertical scaling means increasing the resources of an existing machine. You upgrade your 4-core CPU server to a 64-core monster, boost RAM from 8GB to 256GB, or swap HDDs for NVMe SSDs.
This is the simplest scaling strategy because your software doesn't need any changes. If your app runs on one server today, it still runs on one server after the upgrade - it's just a faster server.
The hard ceiling: every machine has a physical limit. You cannot add infinite CPU or RAM to one box. Once you hit the top-tier AWS r6a.48xlarge (192 vCPUs, 1.5TB RAM), there is literally nowhere to go - and that instance costs ~$10/hour.
Vertical scaling also creates a Single Point of Failure. If that one beefy server crashes, your entire system goes down. No redundancy. For mission-critical systems, this is a disaster waiting to happen.
- -Simple: no code changes, no data partitioning logic.
- -Limited: every machine has a hard physical ceiling.
- -Expensive at the top: high-end servers cost exponentially more for marginal gains.
- -Single point of failure: one server crash = total outage.
- -Downtime during upgrades: you need to halt the server to swap hardware.
Add more servers instead of making one server bigger.
Instead of one super-fast tailor, you hire 100 ordinary tailors. They split the work between them. If one gets sick, 99 others keep working. That is horizontal scaling.
Horizontal scaling means deploying more instances of your application behind a load balancer, allowing you to distribute traffic across many small servers rather than one giant one.
This is the gold standard for web-scale systems. Netflix, Google, Facebook, and Amazon all scale horizontally - they run millions of commodity servers, not a handful of supercomputers.
The magic word here is statelessness. For horizontal scaling to work, each server must be interchangeable. Any request can go to any server. This means you cannot store session data on the server itself - you must push all state to external storage (Redis for sessions, PostgreSQL for data, S3 for files).
Adding more servers is theoretically infinite. AWS auto-scaling groups can grow from 1 to 1,000 instances in minutes based on CPU or request metrics. You can also remove instances during low-traffic periods (like 3am), cutting costs by 90%.
The downside is operational complexity. Now you need a load balancer, service discovery, distributed logging (you cannot SSH into every server), centralized metrics, and database connection pooling.
- -Theoretically unlimited scale - add as many servers as needed.
- -Requires stateless applications (no local session storage).
- -Introduces a load balancer as the traffic distributor.
- -Enables Zero-Downtime deploys via rolling updates.
- -High availability - losing one server doesn't bring down the system.
- -Cost-efficient via auto-scaling (pay only for what you use).
Notice the dependency: horizontal scaling only works cleanly if your logic tier is stateless, which is the exact property HTTP gave you for free back in Module 1. Keep that thread in mind; the next chapter's load balancer and the following chapter's "stateless services" are both direct consequences of this choice.
"Our single database server is struggling. Let's just upgrade it to the biggest instance size available." Good first move?
"Yes, bigger hardware is the simplest fix and avoids any application changes."
"As a short-term bridge, sure: it buys time with zero code changes. But it's a dead end: there's a largest instance size, and you'll hit it eventually. I'd treat it as buying time to build toward a horizontal solution (read replicas, then sharding) rather than the actual fix, especially if growth is fast enough that you'll be back at this ceiling again in months."