What's changed: Initial version (topic 2.13, subtopics 2.13.1–2.13.4)
7.2Capacity Planning and Scalability
Learn the mindset behind capacity planning for future load growth, and the difference between scale up/down (vertical) and scale out/in (horizontal). Understand the prerequisite for scaling out—a stateless design that externalizes databases and sessions—plus automating machine reconfiguration with configuration management tools and VM images, and distributing load with a load balancer or DNS round robin.
As usage grows, the current server setup eventually cannot keep up. Rather than scrambling to add capacity reactively, capacity planning means forecasting future load and deciding in advance when and how to expand. There are two broad directions for expansion, and the choice shapes the system design itself.
7.2.1Scale up/down vs. scale out/in
- Scale up (vertical scaling) strengthens a single machine (more CPU, memory, storage); the reverse is scale down. Simple to implement, but it has a physical ceiling, and upgrading often requires downtime.
- Scale out (horizontal scaling) adds more machines of the same kind to raise capacity; the reverse is scale in. It has a much higher theoretical ceiling, and adding or removing one machine need not stop the whole service—but it presupposes the stateless design described next.
7.2.2Stateless design and automation
- Stateless design means the server itself holds no state (such as session data). Session data is kept off any one server in a shared external store, and the database is likewise separated so every web server can access it. This way, any request reaching any server gets the same result, freeing you to add or remove servers (scale out/in) at will.
- To provision new machines quickly and uniformly, use configuration management tools (e.g., Ansible, applying settings automatically) or VM images (templates with required software pre-baked), eliminating manual machine setup. Avoiding configuration drift as the fleet grows or shrinks is the practical lifeline of horizontal scaling.
- To distribute requests across machines: a load balancer (distributes at the application layer, with health checks and weighting) or DNS round robin (DNS returns multiple IPs for one name in rotation—simple, but it cannot health-check, so it may keep sending traffic to a failed node).
The most common contrast: scale up = vertical, one machine, has a ceiling; scale out = horizontal, more machines, presupposes statelessness. If asked "what precondition enables scaling out," the answer is stateless design (externalizing sessions and the database). Also a staple: DNS round robin, unlike a load balancer, cannot perform health checks.
A classic failure pattern makes this concrete. Suppose a web app keeps login sessions in the application server's local memory. Naively scaling out to two servers now means a request handled and logged in on server A, then routed by the load balancer to server B on the next request, appears logged out because B has never heard of that session—the textbook symptom of "cannot scale out because it is not stateless." The fix is externalizing sessions to a shared store such as Redis, so any responding server can look up the same session data. Likewise, if each server keeps its own local-only config files, adding more nodes means manually duplicating configuration each time, and configuration drift becomes a breeding ground for incidents. This is where configuration management tools (an Ansible playbook applying the same settings idempotently to every node) or cloning new nodes instantly from a pre-baked VM image (with the app already installed) pay off. Capacity planning estimates current peak load, growth rate, and the lead time to scale out (the time from spinning up a new node to it actually serving traffic), so expansion can start before a threshold is breached.
| Approach | What it does | Characteristics |
|---|---|---|
| Scale up / down | Increase/decrease one machine's capacity | Simple, but has a ceiling and often needs downtime |
| Scale out / in | Add/remove machines | High scalability, requires stateless design |
| Load balancer | Distributes across machines | Health checks and weighting available |
| DNS round robin | Returns multiple IPs in rotation | Simple, but no health checking |
Trap: "scaling out means increasing one server's capacity" is wrong—that describes scale up. Scale out means adding more machines. Also wrong: "as long as there is a load balancer, you can scale out even while keeping sessions in application-server memory." A load balancer only distributes traffic; without a stateless design (externalized sessions), servers will disagree about session state.
7.2.3Section summary
- Scale up/down = vertical (one machine, has a ceiling) / scale out/in = horizontal (add/remove machines, high scalability)
- Scaling out presupposes a stateless design (externalized sessions/DB), plus configuration management tools / VM images for uniform provisioning, plus a load balancer / DNS round robin for distribution
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Increasing capacity by growing from one to three identical web servers to handle more traffic is called what?
Q2. What problem tends to occur if you scale out while login sessions remain in each application server's local memory?
Q3. Compared to a load balancer, what is a correct weakness of DNS round robin?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.