Part II · Chapter 2 · One Service · lesson 1
Will it fit on one box?
15 min
Part II · Chapter 2 · One Service · lesson 1
15 min
Five hundred people at one company, and a notes app. They type, it autosaves every few seconds, they search their own notes, they share a folder.
Somebody has already drawn the architecture: three application servers behind a load balancer, a managed Postgres with a read replica, Redis for sessions, all of it across two availability zones.
How many servers does this workload actually need? Commit to a number now, before you read another line.
Predict
Everything here comes from one division: a day holds 86,400 seconds.
A million requests a day sounds like a lot. Divided by 86,400 it is 11.6 requests a second, which is nothing. Ten million a day is 116 a second, which is still nothing. Human activity arrives in per-day units and servers are rated in per-second units, and the number between the two is always 86,400.
Peak is not average, so multiply back up. A consumer app does most of a day in roughly four waking hours, and 24 divided by 4 is 6 — so peak is about six times the flat average unless something specific makes it sharper.
That is the whole method. Users, times actions each per day, divided by 86,400, times the peak multiple. Compare the result to what one box serves.
Five hundred users. Autosave fires on a debounce while somebody is actually typing, so call it a thousand requests per user per day — about eighty minutes of active editing at a save every five seconds. Each save writes a couple of hundred bytes once the row, its index entry and the write-ahead log record are counted.
Can one box hold this?
Hypothetical model, not a forecast
Turns users and actions into requests per second and bytes, then asks how many servers that actually needs over a growth horizon. A period is a year and period 0 is today.
It assumes
It ignores
Hold the bytes, the peak multiple and the server's rating still. Raise the user count until the load today needs a second server, and notice how far you had to drag it.
One action is one request that reaches the server, not one click.
Small reads and writes against a warm cache on a single multi-core box.
| Years from today | Servers the request rate needs | Servers the stored data needs |
|---|---|---|
| 0 | 1 | 1 |
| 1 | 1 | 1 |
| 2 | 1 | 1 |
| 3 | 1 | 1 |
| 4 | 1 | 1 |
| 5 | 1 | 1 |
| 6 | 1 | 1 |
| 7 | 1 | 1 |
| 8 | 1 | 1 |
Not there yet — keep moving the controls.
Average load is 5.8 requests a second. Peak is 34.7. One box rated at five thousand could take 144 times that peak before throughput was the binding constraint, which is the figure the challenge makes you find the hard way: it takes about 72,000 users of this exact shape to need a second machine.
Storage is even less interesting. A hundred megabytes a day, thirty-six gigabytes a year, and 2.7 terabytes accumulated after eight years of growing 50% annually — on a single 8 TB drive, with nothing ever deleted.
One machine. Specifically, as of late 2026: a virtual machine with four dedicated vCPUs and 8 GB of memory — a Hetzner CCX13 or a comparable DigitalOcean premium droplet, somewhere in the region of fifty dollars a month — running three processes under systemd. Your application. nginx terminating TLS in front of it. Postgres 17 on the same disk.
Sessions go in a Postgres table or a signed cookie, not in Redis. Redis earns its place when you have a hit rate to point at, and at 35 requests a second you do not have one.
The one thing I would not skip is the backup, because a single box means a single disk: a nightly base backup plus continuous write-ahead log archiving to object storage, restored onto a scratch machine once so you know the restore works. That is the real cost of one box, and it is a few hours of work rather than a second machine.
There are good reasons to run two, and none of them appear in the arithmetic above.
Deploys. With one box, a restart is a gap in service. Two boxes behind anything that health-checks turns a deploy into a rolling one.
The disk. A failed volume with a tested restore is a few hours of downtime. Whether that is acceptable is a conversation about the business, not about requests a second.
Blast radius during maintenance. Kernel upgrades, Postgres major versions, a full disk from an unrotated log.
Notice that all three are availability arguments. If somebody wants three servers, ask which of those three they are buying — the answer is usually the first one, and the honest version of it is "two, so deploys do not drop requests", not "three, for scale".
Check
That is where this lesson stops holding, and the condition is worth stating precisely: the answer is one box until peak load exceeds one server's rated throughput — about 72,000 users of this shape — or until a request stops being the cheap thing the rating assumed. The second of those arrives far more often than the first.
Because nobody is ever criticised for the diagram with the replica in it.
An over-built system fails slowly and in private: a bill, a deploy pipeline nobody understands, four hours a week of maintenance that never appears on a roadmap. An under-built one fails in public, during a launch, in front of the person who asked whether it would hold.
So the incentive is not symmetric, and the diagram drifts upward. The correction is not to argue about taste. It is to put the division on the whiteboard next to the diagram — users, actions, 86,400, peak multiple — and ask which box in the drawing the load actually requires. That question has an arithmetic answer, which is a different kind of conversation from a preference.