“How many servers do we need?” sounds like a question that needs a research project to answer. It doesn’t — it needs five minutes of napkin math.
Back-of-the-envelope estimation is the habit of turning vague requirements (“we’ll have a lot of users”) into concrete numbers (queries per second, gigabytes of storage, megabits of bandwidth) before you design anything, because every real decision downstream — one database or many, a cache or not, which scaling strategy — depends on roughly knowing the size of the problem first.
The point is never precision. Nobody expects an exact server count from a five-minute calculation. The point is the right order of magnitude — knowing whether you’re building for 100 requests a second or 100,000 completely changes the architecture, and that distinction is visible from rough math alone.
A worked example
A link-sharing app, 10 million daily active users
users posting a link: 1% of DAU post per day = 100,000 posts/day
average post size: ~1 KB (link + metadata)
daily write volume: 100,000 × 1KB = ~100 MB/day
write QPS (spread evenly): 100,000 / 86,400 sec ≈ 1.2 writes/sec
(but real traffic
isn't even — peak
is often 3-5x avg)
peak write QPS: ~1.2 × 4 ≈ 5 writes/sec
reads (10:1 read:write ratio, typical for social content):
peak read QPS: 5 × 10 ≈ 50 reads/sec
storage for 5 years of posts: 100 MB/day × 365 × 5 ≈ 180 GB
(comfortably fits
on one database)
Enter fullscreen mode Exit fullscreen mode
Fifty reads a second and a couple hundred gigabytes of data is a completely different design conversation than fifty thousand reads a second and a couple hundred terabytes — and that difference took one minute of multiplication to surface.
Reference numbers worth memorizing
A handful of reference numbers make this fast:
- A single reasonably-sized application server can typically handle somewhere from a few hundred to a few thousand requests per second, depending heavily on what each request does — simple reads land higher, requests that hit a database or do real computation land lower.
- A relational database on solid hardware handles thousands of simple queries per second.
- A network round trip within the same data center costs roughly 0.5–1ms; a round trip across the country or across an ocean costs 50–150ms.
None of these need to be exact — knowing “a server handles low thousands of req/sec, not millions” is enough to sanity-check any estimate you produce.
A few rules that make this fast
Work in the right units, and convert only at the end. Traffic is usually easiest to reason about in requests per day (from a DAU number) and then converted to requests per second by dividing by 86,400 — but daily active users don’t spread their activity evenly across 24 hours. Real traffic has a peak-to-average ratio, commonly somewhere around 2–5x during a system’s busiest hour, and any capacity plan built only on the average QPS will fall over during the actual peak, which is precisely when it matters most.
Storage math almost always dominates in surprising ways. A feature that feels “small” per item — a 280-character post, a single log line — adds up fast at scale: a million events a day, each 1KB, is a gigabyte a day, 365GB a year, without a single image or video involved. This is usually the number that first forces a “do we need object storage for this” or “do we need to shard this table” conversation, well before raw request volume does.
Round aggressively. 10 million users, not 9.7 million. 1KB per post, not 847 bytes. The entire value of this exercise is speed and directional correctness — spending ten minutes getting a number precise to three significant figures defeats the purpose, when the actual decision only cares whether you’re closer to a hundred, a hundred thousand, or a hundred million.
This estimate becomes the shared vocabulary for every trade-off later in a system design discussion. “Do we need to shard the database” is unanswerable in the abstract, but very answerable once you know you’re expecting 50,000 writes/sec against a single table. “Do we need a CDN” is unanswerable in the abstract, but obvious once you know 80% of your users are outside the region your one server lives in.
This is one topic in the System Design pillar on discoveringCode — a free, ad-free notebook that goes beginner-to-expert on frontend, backend, system design, infra, and AI/LLM engineering. Next up in the pillar: Availability, Reliability & the Nines.