Scalability — Vertical vs Horizontal

Scalability is how a system handles growing load. It is the foundation of every system-design interview: interviewers start small ("one server") and keep adding users until you must scale. Knowing the two directions to scale — and their limits — is table stakes.

The two directions

	Vertical (scale up)	Horizontal (scale out)
How	Bigger machine (more CPU/RAM)	More machines behind a load balancer
Limit	Hardware ceiling, single point of failure	Near-unlimited, but adds complexity
State	Easy (one box)	Needs statelessness / shared store
Cost	Cheap early, expensive at top	Linear, commodity hardware

Real systems scale horizontally for the web/app tier and keep servers stateless (session in Redis/DB) so any request can hit any server.

Exam Tricks & Tips

• 🎯 Default to horizontal scaling for the app tier in interviews — it's how real large systems grow.
• 🎯 Make servers stateless so you can add/remove them freely; push session state to Redis or the DB.
• 🎯 Mention vertical scaling's ceiling and single point of failure as why you switch to horizontal.
• 🎯 Estimate before scaling — do a back-of-envelope QPS/storage calc to justify the design.
• 🎯 Scale the bottleneck, not everything — usually the database becomes the limit first.
• ❌ Common mistake: only scaling the web servers while ignoring the database, which becomes the real bottleneck.

Expected pattern: The starting point of nearly every system-design round; interviewers escalate load to force scaling decisions.

Quick recap: Vertical = bigger box (has a ceiling); horizontal = more boxes + load balancer + stateless servers. Scale the bottleneck.

Cover the answer, recall, then check. 10 cards on scalability.

Q1. Vertical vs horizontal scaling?
A1. Vertical = a bigger machine (more CPU/RAM); horizontal = more machines behind a load balancer.

Q2. Which scaling do large real systems favour for the app tier?
A2. Horizontal scaling (scale out).

Q3. Why keep servers stateless?
A3. So any request can hit any server and you can add/remove servers freely.

Q4. Where do you store session state when stateless?
A4. In a shared store like Redis or the database.

Q5. Limits of vertical scaling?
A5. A hardware ceiling and a single point of failure.

Q6. What usually becomes the first bottleneck?
A6. The database — scale the bottleneck, not everything.

Q7. What should you do before choosing a scale strategy?
A7. A back-of-envelope estimate of QPS and storage to justify the design.

Q8. Common scaling mistake in interviews?
A8. Scaling only web servers while ignoring the database bottleneck.

Q9. Cost profile of vertical scaling?
A9. Cheap early, but expensive as you approach top-end hardware.

Q10. Downside of horizontal scaling?
A10. Added complexity — coordination, statelessness, and a load balancer.

Every system design interview eventually asks "how would this handle 10x the traffic?" — and the first vocabulary you need is scaling. Getting vertical vs horizontal scaling crisp, and knowing why real systems almost always scale horizontally, sets you up for everything else in a design round: load balancers, sharding, and stateless services all follow from this one idea.

What this covers / why it matters: the two ways to scale, their trade-offs, and why horizontal scaling dominates modern architectures. It's the foundation the rest of the system-design chapter builds on.

The approach

Beginner — the two directions

• Vertical scaling (scale up): make one machine more powerful — more CPU, RAM, faster disk. Simple; no code changes. But there's a hard ceiling (the biggest machine you can buy), it's expensive at the top end, and it's a single point of failure.
• Horizontal scaling (scale out): add more machines and spread the load across them. Near-limitless, more fault-tolerant (one node dying isn't fatal), but requires a load balancer and, crucially, that your service can run on many nodes at once.

Intermediate — why horizontal wins, and what it demands

Modern web systems scale horizontally because it's cheaper (commodity machines), more resilient (no single point of failure), and effectively unbounded. But it demands statelessness: each request must be servable by any node, so you push session/state out of the app server into a shared store (Redis, a database). If a server holds user session in local memory, you can't freely add nodes — that's the number-one thing to fix before scaling out.

Advanced — knowing which to reach for

Vertical scaling still has its place: it's the fast first move (just resize the box) and it's often right for a single database primary that's hard to distribute. The mature answer in an interview is: "I'd scale vertically first as a quick win, but design the app to be stateless so I can scale horizontally behind a load balancer as the real long-term path — and I'd tackle the database separately, since that's usually the hardest thing to scale out."

Worked example

"Your web app is slowing down under load. How do you scale it?"

"First I'd figure out where the bottleneck is — app tier or database. If it's the app tier, the quickest fix is vertical: give the server more CPU and RAM. But that has a ceiling and leaves a single point of failure, so the durable fix is horizontal: run multiple app-server instances behind a load balancer. For that to work, the app must be stateless — so I'd move user sessions out of local memory into a shared store like Redis, and keep uploaded files in object storage rather than on the local disk. Then adding capacity is just adding nodes. The database is the harder part: I'd start with vertical scaling plus read replicas for read-heavy load, and only shard if a single primary genuinely can't keep up. So: vertical for a quick win, horizontal + stateless as the real answer, database handled separately."

Names both, justifies the choice, and flags statelessness and the database as the real constraints.

What interviewers look for

• Crisp definitions of scale-up vs scale-out.
• Trade-off awareness — ceiling, cost, single point of failure.
• Statelessness recognised as the enabler of horizontal scaling.
• Sequencing — quick vertical win, then horizontal as the durable path.

Do's and don'ts

• Do explain why horizontal scaling needs stateless services.
• Do treat the database as a separate, harder scaling problem.
• Don't say "just add a bigger server" as the whole answer — note the ceiling.
• Don't forget the single-point-of-failure downside of one big box.
• Mnemonic: UP vs OUT — Up = one stronger box (ceiling, SPOF); Out = more boxes (needs load balancer + stateless).

Worked Example

Problem/Question: "Your single web server is overloaded as traffic grows. Explain vertical vs horizontal scaling and which you'd choose."
Solution/Model answer:
Vertical scaling (scale up): add more CPU/RAM/disk to the single machine.

• Pros: simple, no code changes, no distribution complexity.
• Cons: a hard ceiling (biggest machine you can buy), a single point of failure, and cost grows non-linearly.
  Horizontal scaling (scale out): add more machines behind a load balancer.
• Pros: near-limitless scale, fault tolerance (one node down is survivable), cost-effective commodity hardware.
• Cons: needs statelessness or shared session storage, load balancing, and handling of distributed-data consistency.
  My choice and reasoning: "For a growing web tier I'd scale horizontally — make the app servers stateless (store sessions in Redis), put them behind a load balancer, and add nodes as traffic grows. I'd use vertical scaling only as a quick stop-gap or for components hard to distribute (like a primary database), which I'd later shard or add read replicas to."
  Answer/Takeaway: Vertical scaling adds power to one machine (simple but capped, single point of failure); horizontal scaling adds machines (elastic and fault-tolerant but needs statelessness and a load balancer). For web tiers, prefer horizontal scaling with stateless servers; use vertical as a stop-gap.