What is the difference between horizontal and vertical scaling?

Q: What is the difference between horizontal and vertical scaling?

**Target Audience:** Beginners to system design — you know what a server and a database are, nothing more. **Difficulty:** Medium **Verified with:** Node 22.22 and Python 3.12 (the example prints the same table in both). > **How to read this doc:** Every idea is explained in plain language first, then tagged with `📌 Interview term:` so you also learn the exact words an interviewer expects. Every number below comes from actually running the example program; the **Verified** section quotes its full output. ## 1. Why This Even Matters — A Story First You run a small pizza shop with one oven and one cook. On Friday nights the orders pile up. You have two options. **Option one: a bigger kitchen.** Buy a huge oven, hire a cook who works twice as fast. Nothing else about the shop changes — same phone number, same counter, same recipe book. But there is a largest oven you can buy, the shop is closed while the new one is installed, and if that one cook calls in sick, nobody gets pizza. **

The problem

Question presented to candidate: "Our API is running hot on a single server and traffic keeps growing. You could move it to a bigger machine, or run several copies behind a load balancer. Walk me through the difference between vertical and horizontal scaling, when you would pick each, and what the second option forces you to change."

What a strong answer should cover:

Clear definitions: vertical scaling (scale up) adds CPU, RAM or faster disks to one machine; horizontal scaling (scale out) adds more machines and spreads load across them
Vertical needs no code change but has a hard hardware ceiling, usually needs a restart to resize, and stays a single point of failure
Horizontal gives redundancy and near-elastic capacity, but only if the service is stateless (or the data is partitioned) and a load balancer sits in front
Scaling out is not free: shared bottlenecks (a lock, one primary database) and coordination cost make throughput flatten or even fall (Amdahl's law, Universal Scalability Law)
Availability arithmetic: one node at 99.5% vs N+1 nodes where one may fail; and the usual real path — scale the database up first, scale the stateless tier out, then add replicas and shards

Clarifying questions expected:

Which tier is the bottleneck: the stateless web/API tier or the stateful database?
Is the problem throughput, latency, or availability (do we also need to survive a machine failure)?

Code / implementation expected: Optional — the throughput and availability arithmetic (as in the example) is more useful than code; no implementation is required.

scalability

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Beginners to system design — you know what a server and a database are, nothing more. Difficulty: Medium Verified with: Node 22.22 and Python 3.12 (the example prints the same table in both).

How to read this doc: Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer expects. Every number below comes from actually running the example program; the Verified section quotes its full output.

1. Why This Even Matters — A Story First

You run a small pizza shop with one oven and one cook. On Friday nights the orders pile up. You have two options.

Option one: a bigger kitchen. Buy a huge oven, hire a cook who works twice as fast. Nothing else about the shop changes — same phone number, same counter, same recipe book. But there is a largest oven you can buy, the shop

The solution is hidden so you can try first

13 min read · 11 sections

Read the code

Scale up vs scale out: USL throughput and N+1 availability

Open in playground

// Two numbers that decide "scale up or scale out":
// 1. How throughput grows with node count (Universal Scalability Law).
// 2. How availability changes when one big box becomes several small ones.

const ONE_NODE = 1000; // requests/s one node handles alone (assumption)
const SIGMA = 0.03;    // contention: 3% of the work is serialised (a lock, a primary DB)
const KAPPA = 0.0005;  // coherency: cost of nodes keeping each other in sync

const round = (x) => Math.floor(x + 0.5);
const usl = (n, s, k) => (ONE_NODE * n) / (1 + s * (n - 1) + k * n * (n - 1));

console.log("Throughput (req/s) as nodes are added");
console.log("nodes  linear  amdahl(k=0)  usl");
for (const n of [1, 2, 4, 8, 16, 32, 44, 64, 128]) {
  console.log(
    String(n).padStart(5) +
    String(ONE_NODE * n).padStart(8) +
    String(round(usl(n, SIGMA, 0))).padStart(13) +
    String(round(usl(n, SIGMA, KAPPA))).padStart(7)
  );
}
const peak = Math.sqrt((1 - SIGMA) / KAPPA);
console.log("USL peak at sqrt((1-sigma)/kappa) = " + peak.toFixed(1) + " nodes");
console.log("");

// Availability: each node is up 99.5% of the time, failures independent (assumption).
const A = 0.995;
const HOURS = 365 * 24;
function choose(n, k) {
  let r = 1;
  for (let i = 1; i <= k; i++) r = (r * (n - k + i)) / i;
  return r;
}
// probability that at least `need` of `n` nodes are up
function atLeast(n, need, a) {
  let p = 0;
  for (let up = need; up <= n; up++) p += choose(n, up) * a ** up * (1 - a) ** (n - up);
  return p;
}
function show(label, p) {
  console.log(
    label.padEnd(34) + (p * 100).toFixed(4).padStart(9) + "%" +
    ((1 - p) * HOURS).toFixed(2).padStart(9) + " h/yr down"
  );
}
console.log("Availability with each node at 99.5%");
show("1 big node (scale up)", atLeast(1, 1, A));
show("2 nodes, need 1 (active-passive)", atLeast(2, 1, A));
show("3 nodes, need 2 (N+1)", atLeast(3, 2, A));
show("4 nodes, need 3 (N+1)", atLeast(4, 3, A));
show("3 nodes, need all 3 (no spare)", atLeast(3, 3, A));

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.