Start Here

What scaling actually is

A service that works fine for a thousand users and falls over at a million did not run out of "scale." It ran out of one specific thing first — a CPU pinned at 100%, a disk that cannot seek fast enough, a database connection pool with no free slots, a single lock every request waits behind. That one thing is the bottleneck, and until you find it, every change you make is a guess.

Scaling is the discipline of finding that resource and then doing one of two things: making it bigger (scale up, or vertical scaling) or spreading its work across more machines (scale out, or horizontal scaling). Do either well and the system handles more load — until a different resource becomes the new limit, and you do it again. There is no final state where a system is "scalable." There is only the current bottleneck and the move that clears it.

This reframes the job. You are not building for infinite load; you are buying headroom against the next bottleneck, and every purchase has a price in money, latency, or complexity. A cache that makes reads 50× faster also means your data can be stale. A second database copy that absorbs read traffic also means a write might not be visible on it for a few hundred milliseconds. The skill this guide builds is not memorising the moves — it is knowing which one the situation calls for, and what you are paying for it.

The running example: Snip

Rather than invent a new system each chapter, we carry one the whole way: Snip, a URL shortener with click analytics. A user pastes a long URL, Snip returns a short code like snip.ly/a3Xk9, and from then on every visit to that short link redirects to the original and records a click. It is a deliberately small product, and that is the point — the behaviour is simple enough to hold in your head while the load gets interesting.

Snip is worth carrying because it exercises nearly every scaling problem in one place. Redirects are read-heavy and must be fast — a few milliseconds, because a human is waiting for the page to load — which pulls in caching and read replicas. Clicks are write-heavy and bursty, which pulls in queues and asynchronous processing. The analytics counts are hot keys — a viral link gets millions of hits while most links get none — which pulls in sharding and the awkward problem of counting at scale. And none of it can lose a user's links, which pulls in replication and consistency. One toy product, the whole syllabus.

The two moves, and the loop

Scaling up means a bigger machine: more cores, more memory, faster disks. It is the move to reach for first, because it changes nothing about your code — you reboot on a larger instance and move on. Its ceiling is real, though: the biggest machine money can buy is finite, it is a single point of failure, and the price curve goes vertical at the top end. Scaling up buys you time, not a destination.

Scaling out means more machines sharing the work: a dozen identical app servers behind a load balancer, a database split into shards, reads fanned across replicas. It has no hard ceiling — you add machines as load grows — but it demands something up front. The work has to be divisible, and the moment two machines hold different pieces of the truth, you inherit the hard problems of this guide: how to route a request to the right machine, what to do when one dies mid-request, and whether every machine agrees on what the data says. Most of this guide is the craft of scaling out while keeping those problems small.

Both moves feed the same loop: measure to find the bottleneck, apply the cheapest move that clears it, then measure again. The chapters are ordered the way you actually reach for the tools — the laws first, then the levers, roughly cheapest and most general to most involved.

How this guide is built

Eleven chapters in four sections. Section B is the toolkit you reach for most: the numbers and the laws that bound every system, then statelessness and load balancing, caching, and scaling the database. Section C is the harder middle: consistency and its price, asynchronous work, choosing a data store, tail latency, and reliability. Section D is one worked design that spends every lever on Snip.

Each chapter leads with the mechanism — what the machine is actually doing — then the consequence for your choices, then where it lands on Snip. Recommendations come with the case where they flip. If you only have time for the core, read 00 through 04 and you will have the moves that handle the first two orders of magnitude of growth; the rest is for when those run out.

The reading paths on the guide hub pick a route for your situation — new to backend scale, brushing up, or an interview soon. This is a companion to the data-side systems-design guides on the site; where a topic (ingestion, the warehouse) belongs to the data platform, this guide links there rather than re-teaching it.

Takeaway

• A system does not run out of "scale"; it runs out of one resource first. Find that bottleneck before changing anything.
• There are two moves: scale up (a bigger machine — simple, with a hard ceiling) and scale out (more machines — no ceiling, but you inherit routing, failure, and agreement problems).
• Every move has a price in money, latency, or complexity. The skill is picking the cheapest move that clears the current bottleneck, not applying all of them.
• Scaling is a loop: measure, move, measure again. Each fix exposes the next bottleneck.
• We carry one example — Snip, a URL shortener with click analytics — because its read-heavy redirects, write-heavy clicks, and hot keys exercise the whole syllabus.

Next, the numbers and laws that tell you where the bottleneck will appear before you hit it: The Numbers and the Laws →