Before you commit to an architecture, you need a rough sense of the numbers it must handle: how many requests per second, how much storage per year, how much bandwidth, how many servers. Back-of-the-envelope estimation is the skill of producing those numbers quickly with simple math and a few memorised constants — no spreadsheets, no benchmarks, just enough accuracy to tell whether a design is sensible. This post is a single, flowing walkthrough of the whole skill. You will learn the powers of two that define data units, the latency numbers every programmer should know, how availability is measured in "nines" and tied to SLAs, and a repeatable method for estimating daily active users, QPS, peak traffic, storage, and bandwidth — finishing with a complete worked example. Everything is explained with real-world analogies, a diagram, and step-by-step math, starting from zero.

This is the one Phase 1 topic that is a single flowing subject rather than a set of separate sub-topics. It builds in order: first the raw ingredients every estimate relies on — powers of two, latency numbers, and availability numbers — then the step-by-step method for turning a few assumptions into capacity numbers, and finally a full worked example estimating QPS and storage.

Imagine you're planning the infrastructure for our online store ShopEasy before a big launch. Someone asks: "How many servers do we need? How much database storage for a year? Will one cache fit in memory?" You don't have real traffic yet, and you can't run a benchmark on a system that doesn't exist. What you can do is reason it out on the back of an envelope — a few assumptions, some simple multiplication, and a handful of numbers you've memorised — and arrive at an answer that's roughly right. That's back-of-the-envelope estimation.

As Google's Jeff Dean put it, back-of-the-envelope calculations are "estimates you create using a combination of thought experiments and common performance numbers to get a good feel for which designs will meet your requirements." The goal is never a precise figure — it's an order-of-magnitude answer: is this 10 servers or 10,000? 1 GB or 1 PB? That's usually enough to compare two designs and rule out the ones that can't possibly work.

To do this well, three things need to be second nature: the powers of two that define data sizes, the latency numbers that tell you how slow each operation is, and the availability numbers that translate a percentage like "99.99%" into real downtime. With those in hand, a simple method turns a few assumptions into a full capacity estimate. This post walks through all of it and ends with a complete worked example.

💡 Estimation is about the process, not the exact number. A good estimate shows clear assumptions, sensible rounding, and correct units. Two engineers estimating the same system should land in the same ballpark — that ballpark is what guides the design.

Estimation is what turns a vague idea into an engineering decision. Before writing a line of code, a rough calculation tells you whether the data fits on one machine or needs sharding, whether reads can be served from a cache, and how much the whole thing will cost to run. The numbers involved are huge and non-obvious: Twitter-scale services handle thousands of writes per second and tens of thousands at peak; five years of media can add up to tens of petabytes. Guessing wrong by an order of magnitude means either a system that falls over on day one or a cluster that costs 10× more than needed.

• Feasibility — a quick estimate reveals whether a design is even possible. If one machine can do 10,000 QPS and you need 700,000, you immediately know you need ~70 machines, not one.
• Provisioning — capacity numbers decide how many servers, how much storage, and how big a cache to allocate — and how much to budget.
• Comparing designs — estimates let you rule out approaches cheaply. A design that would need a petabyte of RAM is off the table before you build it.
• Planning for peaks — average load is not what breaks systems; the peak does. Estimation makes you size for the spike, not the average.

Why system design cares: almost every design starts by scoping the problem with numbers — DAU, QPS, storage, bandwidth. Those estimates drive every later choice: SQL vs NoSQL, single database vs sharded, cache or no cache, one region or many. Get the scale right and the rest of the design follows.

Think about catering a wedding. You don't know exactly how many guests will show up or precisely how much each will eat — but you still have to order food and book a venue in advance. So you estimate: "About 200 guests. Say each eats roughly 0.5 kg of food — that's 100 kg. Drinks: 3 glasses each, 600 glasses. Round up for a safety margin." Nobody weighs every plate; a few reasonable assumptions and simple multiplication get you close enough to place the order confidently.

System estimation is exactly this. Guests become users, "how much each eats" becomes requests per user or bytes per item, and the safety margin becomes the peak factor you multiply by so you don't run out during the rush. You'd rather slightly over-cater than have guests go hungry — just as you'd rather provision for the traffic peak than crash during it.

The caterer's skill isn't exact prediction — it's making sensible assumptions, doing quick arithmetic, and building in a margin. Every estimate in this post follows the same recipe: state assumptions, multiply, round, and pad for the peak.

Estimation rests on three sets of numbers you should know cold — powers of two, latency numbers, and availability numbers — plus a repeatable method that turns assumptions into capacity. We'll cover each in turn.

Data volume is measured in bytes, and a byte is 8 bits (one ASCII character fits in a byte). Because computers are binary, storage units are powers of two, but for estimation you round them to the nearest power of ten — that's what makes the mental math easy. Memorise this table:

So a thousand bytes ≈ 1 KB, a million ≈ 1 MB, a billion ≈ 1 GB, a trillion ≈ 1 TB, and a quadrillion ≈ 1 PB. Each step up is ×1,000. When an estimate produces "30 × 10¹² bytes," you instantly read it as 30 TB.

These are the classic latency numbers published by Google's Dr. Jeff Dean. They let you reason about whether an operation is cheap (memory) or expensive (disk, cross-continent network) without measuring. The original 2010 numbers:

📏 Units: ns = nanosecond, µs = microsecond, ms = millisecond. 1 ns = 10^-9 s; 1 µs = 10^-6 s = 1,000 ns; 1 ms = 10^-3 s = 1,000 µs = 1,000,000 ns.

Hardware has improved since 2010. A 2020 visualisation of the same operations shows memory and SSD getting much faster, while the cross-continent network round trip barely changes (it's bounded by the speed of light):

Whichever year's numbers you use, the same five lessons hold:

• Memory is fast, but the disk is slow.
• Avoid disk seeks if possible.
• Simple compression algorithms are fast.
• Compress data before sending it over the internet if possible.
• Data centers are usually in different regions, and it takes time to send data between them.

Availability is the percentage of time a system is operational. 100% means zero downtime; most services live between 99% and 100%. A Service Level Agreement (SLA) is the provider's formal promise of uptime — the big cloud providers (AWS, Google, Azure) set SLAs at 99.9% or higher. Availability is spoken of in "nines," and each extra nine is a big jump: it cuts allowed downtime by ~10×.

Read this the right way round: "four nines" (99.99%) sounds nearly perfect, yet it still allows almost an hour of downtime a year. Chasing more nines is expensive, so you match the target to the service — a payment system aims high, an internal dashboard doesn't need to.

With those constants in hand, every capacity estimate follows the same funnel: start from users, multiply by per-user activity, divide by seconds, then pad for the peak. Here is the repeatable recipe:

Let's make the recipe concrete by carrying one simple example through every step. Suppose we're sizing a photo-sharing app. We'll keep the numbers round on purpose — that's the whole spirit of estimation.

📋 Our assumptions: 20 million monthly users · 50% use it daily · each daily user uploads 1 photo and views 100 photos per day · each photo is 2 MB · data kept for 5 years · peak is 2× the average · one server handles ~1,000 requests/second.

Step ① — Write down your assumptions. Before any math, list what you're assuming: how many users, what each user does per day, how big each item is, how long you keep data, and how spiky traffic is. This is the most important step — every later number depends on it, and writing it down lets anyone check your reasoning. (Ours are in the box above.)

Step ② — Daily Active Users (DAU). Traffic comes from the people active today, not everyone who ever signed up. So convert monthly users to daily users with the "percent active daily" assumption. Our app: 20 million × 50% = 10 million DAU. Every other estimate starts from this one number.

Step ③ — Average QPS (requests per second). Take the total actions in a day and spread them evenly across the day's seconds. There are 86,400 seconds in a day, which we round to ~100,000 to make the division trivial. Do reads and writes separately, because they usually differ wildly. Our app (writes): 10 million uploads ÷ 100,000 ≈ 100 write QPS. Our app (reads): 10 million × 100 views = 1 billion views ÷ 100,000 ≈ 10,000 read QPS. Notice reads are 100× writes — that's typical.

Step ④ — Peak QPS. The average hides the busy hours. Multiply by a peak factor (×2 for steady apps, ×3+ for spiky ones like sales or viral moments) and design for that, because the peak is what crashes a system. Our app: writes ≈ 100 × 2 = ~200 peak QPS; reads ≈ 10,000 × 2 = ~20,000 peak QPS.

Step ⑤ — Storage per day. Only writes add to storage (reads don't create data). Multiply the number of new items per day by the size of each. Our app: 10 million uploads × 2 MB = 20 TB per day. (10 million × 2 MB = 20 million MB = 20 TB.)

Step ⑥ — Total storage. Multiply daily storage by the retention period. A quick shortcut: one year ≈ 365 days. Our app: 20 TB/day × 365 × 5 years ≈ 36,500 TB ≈ ~37 PB. That instantly tells us photos can't live in a normal database — they belong in object storage.

Step ⑦ — Bandwidth. Bandwidth is data moved per second. Split it into ingress (data coming in — uploads) and egress (data going out — views). Take the data per day and divide by ~100,000. Our app (upload/ingress): 20 TB/day ÷ 86,400 s ≈ ~230 MB/s. Our app (view/egress): 10 million × 100 views × 2 MB = 2 PB/day ÷ 86,400 s ≈ ~23 GB/s. Egress dwarfs ingress — which is exactly why a read-heavy media app leans on a CDN.

Step ⑧ — Number of servers. Divide the peak load by what one server can handle, then add headroom so a couple of failures don't sink you. Our app: peak reads 20,000 QPS ÷ 1,000 per server = 20 servers, plus ~30% headroom ≈ ~26 servers for the read path (writes need only ~1). In reality a cache would absorb most reads, cutting this sharply — but the estimate sets the upper bound.

Put the whole walk-through together and you have a complete capacity picture from six lines of arithmetic:

Two shortcuts make the arithmetic painless. There are 86,400 seconds in a day, which for rough math you can round to ~100,000 (10⁵). And most systems are read-heavy — reads outnumber writes, often 10:1 or 100:1 — so estimate the write path and the read path separately, and expect reads to be served largely by caches and replicas rather than the primary database.

📌 Always size for the peak. Average QPS keeps the lights on; peak QPS is what crashes you. Multiply by a peak factor (×2–×3, higher for spiky workloads like flash sales or viral posts) and provision servers for that number, not the daily average.

A handful of estimate types come up in almost every design. They all use the same funnel from Section 1.5, just with different per-unit numbers.

The read/write split matters. Because most systems are read-heavy, traffic and server estimates are usually done separately for reads and writes. Writes hit the primary database; reads are absorbed by caches and replicas — so a system with 7,000 write QPS might serve hundreds of thousands of read QPS from cache.

The diagram shows the estimation funnel. A few assumptions flow into DAU, which branches into the traffic path (QPS → peak QPS → servers) and the data path (storage per day → total storage, and bandwidth).

Reading the diagram: everything starts from assumptions and DAU. The left branch answers "how much compute?" (QPS, peak, servers); the right branch answers "how much data?" (storage and bandwidth). Follow both branches and you have a complete capacity picture.

Back-of-the-envelope estimation is for the early, decision-making phase — when a rough number is enough to choose a direction. Once a system is live, you replace estimates with real measurements.

The math itself should stay deliberately sloppy. Round aggressively and approximate — precision is not the point:

Rule of thumb: estimate to choose, measure to tune. Use round numbers, always compute the peak (not just the average), and always label your units. If a quick estimate says a design needs a petabyte of RAM, you've saved yourself from building it — that's the whole value.

Let's run the full method on a classic example: estimate the QPS and storage for a Twitter-like service. (These numbers are illustrative, not real Twitter figures.) We start by writing down assumptions.

QPS estimate — how many tweets per second the write path must handle:

Storage estimate — we'll estimate media storage, since it dwarfs text. First, the size of one tweet:

What the numbers tell us: ~7,000 writes/second at peak is comfortably within reach of a sharded database, but 55 PB of media over five years clearly can't live in one database — it belongs in object storage behind a CDN (from the earlier posts). In a few lines of arithmetic, the estimate has already shaped the architecture. Reads aren't shown here, but since the service is read-heavy they'd be far higher than writes and served largely from cache.

The whole point of estimation is trading precision for speed. Knowing what you gain and give up keeps you from over- or under-trusting the result.

📌 The core tension: estimation trades accuracy for speed and clarity. That trade is exactly right when choosing a design and exactly wrong when you need the real number — so estimate to decide, then measure the running system to confirm and tune.

• Estimation gives order-of-magnitude answers — fast capacity numbers that guide the design before anything is built.
• Know the constants — powers of two (KB→PB, ×1,000 each step), latency numbers (memory fast, disk slow, cross-region ~150 ms), and availability nines.
• Follow the funnel — assumptions → DAU → QPS → peak QPS → servers, and DAU → storage → bandwidth.
• Always size for the peak — multiply average QPS by a peak factor; estimate read and write paths separately since systems are read-heavy.
• Round, label units, write assumptions — the process matters more than the exact figure; estimate to decide, then measure to tune.

🛒 Challenge: Estimate ShopEasy's capacity

Estimate the traffic and storage for our online store. Use these assumptions:

• 40 million monthly active users; 25% shop on any given day.
• Each daily user views 20 product pages and places 0.1 orders on average.
• Each order record is about 1 KB; keep orders for 5 years.

Work out: (a) DAU, (b) page-view QPS and its peak, (c) orders per day, and (d) 5-year order storage.

👁️ Show Answer

(a) DAU: 40 million × 25% = 10 million daily active users.

(b) Page-view QPS: 10 million × 20 views ÷ 86,400 s ≈ 200 million ÷ 86,400 ≈ ~2,300 QPS. Peak = × ~3 (shopping is spiky — evenings, sales) ≈ ~7,000 QPS. These are reads, so they're served largely from cache and replicas.

(c) Orders per day: 10 million × 0.1 = 1 million orders/day → order-write QPS ≈ 1,000,000 ÷ 86,400 ≈ ~12 QPS (tiny — a single primary handles this easily, with peaks well within reach).

(d) 5-year order storage: 1 million/day × 1 KB = 1 GB/day → 1 GB × 365 × 5 ≈ ~1.8 TB. That fits comfortably in a single relational database — no sharding needed for orders yet.

What it tells us: reads dominate (thousands of QPS) and drive the caching/replica strategy, while writes and order storage are modest. The estimate says: cache hard for product pages, keep orders in one SQL database. That's a real architectural decision from five minutes of arithmetic.

Estimation isn't a service, but three cloud offerings connect directly to it: the SLAs that back your availability numbers, the pricing calculators that turn capacity estimates into cost, and the monitoring that replaces estimates with real numbers once you're live.

Simplest picture: use your QPS and storage estimates in a cloud pricing calculator to get a monthly cost before you build, rely on the provider's SLA for the availability target, and once the system is running, watch CloudWatch (or the equivalent) to see how close your envelope math was — then adjust capacity from real data.

---