The Capacity Estimation Numbers Every Engineer Should Carry Into a System Design

There is a moment in almost every system design conversation, interview or real, where someone reaches for an architecture before anyone has worked out how big the problem actually is. Caches, queues, shards, read replicas, all proposed before a single number has been written down. It is the most common mistake I see senior engineers make, and it is completely avoidable.

So I built a page to fix it. It is the reference sheet for Session 2 of my From Senior to Staff cohort, Capacity Estimation and Requirements, and I want every engineer to read it before they design anything: hub.gazar.dev/senior-to-staff/s02-capacity-estimation. Open it in another tab, then come back, because in this article I want to explain why this short list of numbers and formulas matters far more than its length suggests.

Estimation is not maths, it is the gate before the design

The first thing the page reframes is what estimation is even for. People hear "capacity estimation" and brace for a spreadsheet. That is the wrong picture.

You are not building a model. You are finding the single estimate that decides whether this fits on one node or needs a fleet. That is the whole game. One number that bounds the design. Everything downstream, the database choice, the need for a cache, whether you can get away with a monolith or genuinely need to distribute, falls out of that one bounding number. Estimate first, architect second. Do it the other way around and you are decorating a guess.

This is also where the senior-to-staff gap shows up most clearly. A senior engineer jumps to the components they know. A staff engineer asks how big this is first, because they know the answer changes the entire shape of the system.

The toolkit: five formulas that cover most of the work

The core of the page is a small toolkit you can hold in your head. There is nothing clever in it, and that is the point. It is deliberately small so you can actually use it under pressure.

• QPS from users: daily actives × actions/day ÷ 86,400, then × peak factor. This is how you get from a product fact you can ask for ("how many daily users?") to a load number you can design against.
• Storage: items × bytes/item × retention × replication. The two terms people forget are retention and replication, and they are usually the ones that turn gigabytes into terabytes.
• Bandwidth: QPS × payload size, both directions. Egress is the one that quietly costs money and saturates links.
• Memory and cache: look at the hot set size and ask whether the working set fits in RAM. That single question decides whether a cache is a nice-to-have or load-bearing.
• Latency budget: allocate the time you are allowed across the hops in the request, so you know early if your design can even hit the target.

If you can run those five in your head, you can size most systems well enough to make the right architectural call. That is all estimation is for.

The numbers you should carry in your head

The part of the page I most want people to memorise is the latency reference. These are the numbers every engineer should know cold:

RAM ~100ns · SSD ~100µs · same-DC ~0.5ms · cross-region ~70ms+

Once those four live in your head, a huge class of design questions answers itself. Why is the cache hit so much cheaper than the database read? Look at the gap between RAM and SSD. Why does that one cross-region call dominate your p99? Because 70 milliseconds is enormous next to everything around it. You stop guessing about where the time goes and start reasoning about it, which is exactly the kind of thinking that turns into a defensible latency budget once the system is live.

Understanding the limits is what tells you when to scale

This is the heart of it, and the reason the page exists. You cannot know when to scale until you know the limits.

"We need to scale" is a meaningless sentence on its own. Scale what, past what, why? The numbers turn that vague anxiety into a precise trigger. When you know a single modern box does on the order of tens of thousands of simple operations a second, and you have estimated your peak QPS, the question stops being a feeling and becomes arithmetic. Does this fit on one node, or do I genuinely need a fleet? That is the only scaling question that matters, and you cannot answer it without the estimate in front of you.

Two principles on the page make this honest:

• Design for peak, not average. Real traffic is spiky, so you plan for ×2 to ×10 over the mean. The system that falls over is almost never the one that could not handle the average; it is the one that was never sized for the peak.
• Order of magnitude is usually enough. Is this 10s, 1000s, or millions? That alone picks the shape. You rarely need precision. You need to know which power of ten you are in, because the architecture for thousands and the architecture for millions are different animals.

Knowing the limits is also what stops you over-engineering in the other direction. Half the "we need microservices and Kafka" instincts evaporate the moment you estimate the real load and realise one well-chosen database would carry it for years. Estimation protects you from scaling too early just as much as too late, and it pairs directly with knowing your horizontal and vertical scaling options and the concrete strategies for scaling a database when the numbers finally do demand it.

How to actually say this in an interview

Here is where this becomes worth real money, because the interview rewards the reasoning, not just the answer.

Most candidates either skip estimation entirely and start drawing boxes, or they freeze trying to compute an exact figure. Both lose. The move that signals seniority is to estimate out loud, fast, and with stated assumptions. The line from the page I would tattoo on every candidate is this:

A stated wrong number beats an unstated right one.

Say your assumption. "Let us assume 10 million daily actives, each doing about 20 writes a day." Run the formula in the open. "That is 200 million writes over 86,400 seconds, so roughly 2,000 to 2,500 per second average, call it 10,000 at peak." Then turn the number into a decision: "10,000 writes a second is comfortably within one strong database for now, so I will not shard yet, but here is the threshold where I would." That last sentence is the staff-level move. You named the number, you made the call, and you named the condition that would change it.

That pattern, assume → estimate → decide → name the trigger, is the spine of how I teach the whole first ten to twenty minutes of a system design interview, and it sits right on top of the work of splitting functional from non-functional requirements and turning the non-functional ones into numbers. Estimation is the bridge between "what the system must do" and "what the system must withstand."

Read the page before your next design

I am genuinely proud of how tight this reference is, and tightness is the feature. It is short enough to read in a few minutes and to actually keep in your head, which is the only form of knowledge that helps you when the clock is running and someone is waiting for you to talk.

So before your next design review, before your next interview, before the next time you are tempted to reach for a queue, read it: hub.gazar.dev/senior-to-staff/s02-capacity-estimation. Then make the estimate your first move, every time. It is the cheapest habit in engineering and one of the highest-leverage. This is the same trade-off-first thinking I wrote about after the first live cohort session: the goal is never the perfect answer, it is the defensible decision, and the numbers are what make it defensible.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and interview reasoning on Gazar Breakpoint on YouTube.

And if you want to be in the room for sessions like this one, my next free live session is System Design for AI Agents: Senior vs Staff (Tuesday, July 21, 2026, 6:30 PM GMT+1, 45 minutes on Zoom), which points the same trade-off-first thinking at the hardest version of the problem: designing around a dependency that is non-deterministic. My courses and other free lessons are on my Maven profile.