Back-of-envelope estimation

Back-of-envelope estimation is quick arithmetic, done out loud, that turns a few stated assumptions into the numbers that pick a design: requests per second, bytes stored, bytes moved, memory needed and machines required. You are after the right power of ten, not the right decimal. If peak writes are 40 a second, one database will do; at 400,000 a second you need shards, and no extra precision changes that.

Picture it first: the wedding caterer

A caterer quoting for a wedding doesn’t count grains of rice. She asks three questions: how many guests (500), how much each eats (four rotis), and when they eat (almost everyone between 9 and 10 pm).

Then she does the arithmetic out loud. 500 × 4 = 2,000 rotis. One cook makes about 100 an hour. Spread over a five-hour evening that is 400 an hour, so 4 cooks. But everyone eats in the same hour, so she needs 2,000 ÷ 100 = 20 cooks, plus two spare for the cousins nobody invited. Whether 487 or 513 guests turn up, the answer is still “about twenty cooks”, and that is the only number she needs.

Map it back:

• Guests are daily active users; rotis per guest are requests per user.
• The dinner hour is the peak factor: here 5× the evening average.
• A cook’s rate is per-server capacity; the spare cooks are headroom.
• The quote (4 cooks or 22, one tawa or twenty) is the design decision: one server or a fleet.

Why estimate: every number should pick a box

Estimation in a design round is not a maths test. Each number exists to settle one decision, and you should name the decision before you calculate. Jeff Dean’s 2009 LADIS keynote calls the ability to estimate a design’s performance “without actually having to build it” an important skill. Google’s SRE workbook calls the practice non-abstract large system design: turning a whiteboard sketch into concrete resources, where sound reasoning matters more than the final value.

Estimates pick latency designs as well as capacity. Dean’s slide sizes an image results page with 30 thumbnails, using his era’s 10 ms disk seek and 30 MB/s read. Reading serially costs 30 × 10 ms + 30 × 256 KB ÷ 30 MB/s ≈ 560 ms; issuing the reads in parallel costs one seek plus one read, ≈ 18 ms (30–60 ms once variance is counted). One line of arithmetic, and the design is “read in parallel”.

The test for any estimate: would a different answer change what you draw?

The method in seven steps

1. State assumptions. Daily active users (DAU), actions per user per day, object sizes, read:write ratio, retention. Write them where the interviewer can see and correct them. Eskildsen’s napkin-math warns that more than about six assumptions means you are overcomplicating it.
2. Convert units. Per day to per second (÷ 86,400, or roughly ÷ 10⁵); bytes to bits for network links (× 8).
3. Compute the average. Daily total ÷ 10⁵ gives the mean rate.
4. Apply a peak factor. Machines must survive the busiest hour and minute, not the mean.
5. Add copies and overhead. Replicas (usually 3), indexes, per-key overhead in caches, and headroom so servers run at 50–70% rather than 100%.
6. Sanity-check. Divide back to a per-user figure, or compare with a published number or one machine’s capacity.
7. State the decision. “So writes fit on one primary” or “so we need about 18 shards”.

Conversions and rounding

Most of the speed comes from a handful of conversions you never recompute.

And a short list of the values this article plugs in. The full reference, with latencies and per-technology throughput, lives in numbers to know.

Rounding rules

• Keep one significant figure, two at most. 9,286 becomes 9,000. Being 2× off is fine; 10× off is a different design.
• Write numbers as c × 10ᵉ. Multiply the coefficients, add the exponents. Napkin-math’s advice: get the exponent right, because the coefficient matters much less.
• Keep units on every line. They catch mistakes. The SRE workbook’s query-log estimate shows the style: (5 × 10⁵ queries/s) × (8.64 × 10⁴ s/day) × (2 × 10³ bytes) = 86.4 TB/day, then rounded up to 100 TB for indexes and click logs.
• Round in the safe direction. Round sizes and rates up, per-node capacity down. An estimate that errs toward more machines fails gracefully; one that errs toward fewer fails in production.

Read/write ratios and peak factors

These two multipliers decide more designs than raw traffic does.

Read:write ratio

Derive it from how often one thing is read after it is written. A short link is created once and clicked perhaps 100 times. A payment is written once and read a few times (status checks, a statement line), so traffic is close to 1:1. A photo is read hundreds of times: Facebook’s 2010 Haystack paper reports about 120 million uploads and 80–100 billion photo views a day, so (80 to 100) × 10⁹ ÷ 1.2 × 10⁸ ≈ 670 to 830 reads per write. The same table shows only about 10 billion reads a day reaching Haystack itself: CDNs and caches absorbed around 90%.

A high ratio makes caches, read replicas and CDNs the design (see scaling reads). A ratio near 1:1 makes the write path the design: partitioning, batching, append-only logs (see scaling writes).

Peak factor

The average is the daily total ÷ 86,400. Machines must survive the busiest minute. Pick the factor in three layers:

1. Daily rhythm. Peak factor ≈ (share of the day’s traffic in the busiest hour) × 24. If 10% of a delivery app’s daily orders arrive between 8 and 9 pm, the peak hour runs at 0.10 × 24 = 2.4× the average.
2. Bursts inside the hour. Minutes are uneven too. Unless you know better, allow roughly another 1.5×.
3. Events. Compute these from the event, not the day. In August 2013 Twitter reported a one-second peak of 143,199 tweets against a normal 500 million a day, about 5,700 a second: 143,199 ÷ 5,700 ≈ 25×. For a tatkal-style booking window, suppose (hypothetically) 1 million people each make 10 requests in the first 5 minutes: 10⁷ ÷ 300 s ≈ 33,000 requests/s, whatever the daily average says.

A 2–3× daily peak is absorbed by headroom and autoscaling. A 25× event spike is not: autoscaling typically reacts in minutes, and the spike lasts seconds. That calls for pre-scaled capacity, queues, waiting rooms or load shedding, which is why a flash sale is designed differently from a feed.

Worked example 1: UPI-scale payments from a published count

Start from a real number. RBI’s Payment System Indicators for September 2026 report 240,683.80 lakh UPI transactions (provisional). A lakh is 10⁵.

• Per month: 240,683.80 × 10⁵ ≈ 2.4 × 10¹⁰ transactions.
• Per day: 2.4 × 10¹⁰ ÷ 30 = 8 × 10⁸, about 800 million a day.
• Average rate: 2.4 × 10¹⁰ ÷ 2.6 × 10⁶ s ≈ 9,000 TPS (unrounded: 2.407 × 10¹⁰ ÷ 2,592,000 = 9,286).
• Shortcut check: 8 × 10⁸ ÷ 10⁵ = 8,000/s, 14% low, exactly as the rule predicts.

Peak. Assume the busiest hour carries 8% of the day (0.08 × 24 ≈ 2×) and its busiest minute runs 1.5× the hour: 2 × 1.5 = 3. So 9,300 × 3 ≈ 28,000, call it 30,000 TPS at peak.

Fan-out. In a simplified four-party model (payer’s app, a central switch, the payer’s bank, the payee’s bank), assume about 4 request-response exchanges pass through the switch per payment: 30,000 × 4 = 120,000 messages/s at peak.

Storage. Assume 1 KB per transaction record (IDs, two payment addresses, amount, timestamps, status, references, rounded up): 8 × 10⁸ × 1 KB = 800 GB a day, or 2.4 TB with three copies. Per year: 800 GB × 365 ≈ 290 TB raw, about 0.9 PB with three copies. Add an assumed 30–50% for secondary indexes (by payer, by payee, by reference) and the total is about 1.1–1.3 PB a year.

Sanity checks.

• RBI reports ₹29.4 lakh crore of UPI value for the same month: 2.94 × 10¹³ ÷ 2.41 × 10¹⁰ ≈ ₹1,220 per transaction. Mostly small everyday payments, which matches how UPI is used.
• RBI’s count excludes failed transactions, so the switch sees more attempts than successes: one more reason for headroom.
• Twitter’s 2013 average was about 5,700 tweets a second. A nationwide payment network averaging about 9,000 a second is the same order of magnitude.

Decision. Thirty thousand payments a second at peak, each writing several ledger rows, plus about a petabyte a year: this cannot be one database. You need a partitioned ledger and a hot/archive split. Example 4 sizes it.

Worked example 2: photo storage per day and per year

Assumptions for a hypothetical photo app: 100M DAU; one user in ten uploads one photo a day, so 10⁷ photos a day; the original is 2 MB after client-side compression; three resized versions (feed, preview, thumbnail) add 0.5 MB; three copies of everything; 1 KB of metadata per photo including indexes; keep everything five years.

• Upload rate: 10⁷ ÷ 10⁵ = 100 uploads/s, 300 at peak. Trivial: writes per second are not the problem here; bytes are.
• Raw per day: 10⁷ × 2.5 MB = 2.5 × 10⁷ MB = 25 TB a day.
• With three copies: 25 × 3 = 75 TB a day.
• Per year: 25 TB × 365 ≈ 9.1 PB raw, × 3 ≈ 27 PB a year.
• Five years, flat traffic: 27 × 5 ≈ 137 PB.
• Metadata: 10⁷ × 1 KB = 10 GB a day, about 11 TB a year with copies, under 0.05% of the blobs.
• Ingress: only originals are uploaded: 10⁷ × 2 MB = 20 TB a day ÷ 86,400 ≈ 230 MB/s, or about 2 Gbps on average and 6 Gbps at peak. Modest once spread across upload servers.

Haystack confirms the multiplier structure. Facebook wrote 12 times as many photos to Haystack as users uploaded, because each image was scaled to 4 sizes and each size saved in 3 places: 1.2 × 10⁸ × 4 × 3 = 1.44 billion writes a day, exactly the figure in the paper. The paper also reports about 60 TB for a billion new photos a week, which is 60 KB per photo in 2010. At today’s 2.5 MB, the same billion photos would be 2.5 PB a week. Object size is usually the assumption that moves the answer most, so say it clearly.

Decision. Images go to object storage; metadata goes to a database; 27 PB a year rules out storing images in the database. Then estimate cost, because it shapes the design too. Napkin-math lists regional blob storage at about $0.02 per GB-month, and managed object storage typically bills logical bytes with its redundancy included: 9.1 × 10⁶ GB × $0.02 ≈ $180,000 a month for one year of photos, and about $900,000 a month by year five.

That bill is why photo platforms tier their storage. Facebook’s f4 paper found request rates for week-old blobs an order of magnitude lower than for blobs less than a day old, and moved this warm data to erasure-coded storage, cutting the effective replication factor from 3.6 to 2.1. At 2.1 instead of 3, our first year is 9.1 × 2.1 ≈ 19 PB instead of 27.

Egress. Assume each user views 50 photos a day at 200 KB each: 10⁸ × 50 = 5 × 10⁹ views × 2 × 10⁵ bytes = 10¹⁵ bytes, a petabyte a day. Divided by 86,400 that is about 1.2 × 10¹⁰ bytes/s, or 90 Gbps on average and about 280 Gbps at a 3× peak. A CDN is mandatory. And 5 × 10⁹ views ÷ 10⁷ uploads = 500:1, close to the ratio Facebook reported, so the assumptions hang together.

Worked example 3: URL shortener reads and the hot set

Assumptions: 100M new short links a month; each is clicked 100 times over its life; 500 bytes per link record including its index; three copies; five-year retention.

• Writes: 10⁸ ÷ 2.6 × 10⁶ s ≈ 40/s; 120/s at a 3× peak.
• Reads: 40 × 100 = 4,000/s; 12,000/s at peak.
• Storage: 10⁸ × 500 B = 50 GB a month, 600 GB a year, 3 TB in five years, 9 TB with copies.
• Daily reads: 4,000 × 86,400 ≈ 3.5 × 10⁸.
• Hot set: clicks are skewed toward recent and viral links. A safe upper bound is to cache 20% of a day’s reads: 0.2 × 3.5 × 10⁸ × 500 B ≈ 3.5 × 10¹⁰ B = 35 GB. It overcounts, because repeat clicks on one link are counted every time, and that is the safe direction. Add 50% for the cache’s per-key bookkeeping: about 50 GB.
• Database reads after the cache: assume 90% of reads hit the cache; then 12,000 × 0.1 = 1,200 reads/s at peak reach the database.
• App servers: 12,000 ÷ 2,000 = 6, plus spares.
• Egress: 12,000 × 500 B = 6 MB/s ≈ 48 Mbps.

Decision. One database primary with replicas, no sharding for years; one cache node plus a replica; bandwidth is irrelevant. That is a useful result: the hard parts of a URL shortener are generating short, unique IDs (unique ID generator) and keeping the redirect path fast, not raw scale. Had the hot set come out at 5 TB, you would be designing a distributed cache instead.

Worked example 4: servers and shards from per-node capacity

Back to the payment switch from example 1: 30,000 payments/s and 120,000 messages/s at peak, and 800 GB of ledger data a day.

Per-node capacity is an assumption, so say it out loud. Twitter’s 2013 post shows how wide the range is: its Rails hosts served 200–300 requests a second, while its JVM services pushed 10–20K per host. That is a 50× spread for broadly similar work. For typical figures by technology, see numbers to know.

App servers. Assume 2,000 messages/s per server at a comfortable 60% CPU: 120,000 ÷ 2,000 = 60 servers. Spread them across three zones and survive losing one: the two remaining zones must carry everything, so 60 × 3 ÷ 2 = 90 servers, 30 per zone.

Ledger writes. Each payment writes a debit entry, a credit entry and a status update, so 3 writes: 30,000 × 3 = 90,000 writes/s at peak.

• On a managed store with published limits: a DynamoDB partition supports up to 1,000 write units a second, one unit being a write of up to 1 KB. 90,000 ÷ 1,000 = at least 90 partitions, and more in practice, because keys never spread perfectly.
• On self-managed SQL shards: assume a primary comfortably sustains 10,000 small durable writes a second, and keep 2× headroom for uneven keys and growth: 90,000 ÷ 10,000 × 2 = 18 shards.

Storage per shard. Assume you keep each shard under about 4 TB so backups, restores and re-sharding stay quick. Keeping a full year online: 292 TB ÷ 4 TB ≈ 75 shards; now storage, not writes, decides the count. Keeping 90 days hot and archiving older entries to cheaper storage: 800 GB × 90 = 72 TB ÷ 4 TB = 18 shards, which agrees with the write count.

Total. 18 shards × 3 copies = 54 database nodes, plus 90 app servers. Shard by account so a payment’s ledger rows stay together (see database sharding).

The same “largest constraint wins” rule runs through the SRE workbook’s exercise. A day of query logs, rounded to 100 TB, held in RAM on 64 GB machines needs 100 TB ÷ 64 GB ≈ 1,563 machines; written one entry per I/O to disks managing 200 IOPS each, 5 × 10⁵ ÷ 200 = 2,500 disks. Neither number is about CPU, and both rule out a single machine.

Going deeper: sanity checks and failure modes

Sanity checks that catch 10× errors

• Divide back to one user. Example 2’s 9.1 PB a year ÷ 10⁸ users ≈ 91 MB per user, or about 36 photos at 2.5 MB. That matches “one user in ten posts daily” (36.5 a year), so the chain is consistent.
• Cross-check two ways. Top-down from a published total (RBI’s monthly count) and bottom-up from users × actions should land within a few × of each other.
• Compare with a known system. Facebook reported serving over a million images a second at peak in 2010. If a new app’s estimate beats that, recheck it.
• Ask whether it fits on one box. If a whole dataset fits in one machine’s RAM, many “distributed” questions disappear.
• Check the units again. Per day versus per second, bits versus bytes, KB versus KiB.

Averages hide skew

Per-partition limits apply per partition. Ninety partitions of write capacity don’t help if one large merchant receives 5% of all payments: 90,000 × 0.05 = 4,500 writes/s on one key, far above a 1,000-unit partition. Estimate the hottest key, not just the total, then plan key splitting or write sharding (see hot keys).

Utilisation is not 100%

Plan servers at 50–70% busy, not 100%. Queueing delay rises steeply as a server approaches saturation, so “exactly enough” capacity means slow responses at peak (see latency vs throughput vs bandwidth).

Growth and amplification

Dean’s advice is to make sure a design works if scale changes by 10× or 20×, while accepting that the right solution at X is often not optimal at 100×. So estimate one to two years ahead and say what you would change at 10×; don’t build for 100× today. Also count multipliers that hide in the request path: fan-out (one page, 30 thumbnail reads), retries during incidents (a retry storm can double load at the worst moment) and secondary indexes that turn one logical write into several physical ones.

Cheat sheet

How to say it in the interview

“Before I draw boxes, let me check three numbers that decide the design. Assume 100 million daily users, each creating one thing and reading fifty. Writes: 10⁸ a day over about 10⁵ seconds is 1,000 a second, call it 3,000 at peak; one primary can take that. Reads at 50:1 are 50,000 a second at average, 150,000 at peak, so caching is the design, not optional. Storage: 1 KB a write is 100 GB a day, about 36 TB a year, 110 TB with three copies; I’ll shard by user once that outgrows a few terabytes per node. I’ve rounded everything to one significant figure; tell me if any assumption is off.”

Your number is off by 10×. Does it matter? Only if it crosses a decision threshold. In the URL shortener, 400 writes a second instead of 40 still fits one primary, so no. A 500 GB hot set instead of 50 GB turns one cache node into a sharded cluster, so yes. Say which side of the threshold you are on and how far.

How do you pick a peak factor? Multiply the busiest hour’s share of daily traffic by 24 (10% gives 2.4×), then allow for bursts within the hour. For events such as a sale opening, a match final or a tatkal window, compute load from the event itself (users × requests ÷ window), because the daily average says nothing about it.

Do you need to estimate at all? Not always. If the interviewer gives the scale, or the numbers obviously fit one machine, say so and move on. Many interviewers prefer estimates done when they change a decision, often during a deep dive, rather than as an upfront ritual (see the delivery framework).

How precise should I be? One significant figure, units on every line, rounded in the safe direction, and no more than a few minutes. The interviewer is grading the reasoning and the decision, not the decimals.

Isn’t rounding 86,400 to 10⁵ 14% wrong? Yes, and it doesn’t matter: peak factors and size assumptions carry far more uncertainty than 14%. If a result sits right on a threshold, redo that one line with 86,400, or remember that 1M a day is 12 a second.

Where to go next

• Numbers to know: the latencies, throughputs and sizes you plug into these formulas.
• The delivery framework: when in the round to estimate, and how long to spend.
• How a system design interview works: what interviewers are scoring while you calculate.
• Common mistakes that sink design rounds: premature sharding and estimates that decide nothing.
• Scalability: what to do once the numbers say one machine is not enough.
• Latency vs throughput vs bandwidth: the units, Little’s law and why utilisation targets exist.
• Database sharding: turning a shard count into a partitioning scheme.
• Caching 101: hit ratios and what a hot set means in practice.
• Design a URL shortener and design a rate limiter: full designs whose estimates sections use this method.

References and further reading

1. Non-Abstract Large System Design (Google SRE Workbook, chapter 12)sre.googleScientific-notation arithmetic, rounding a log entry up to 2 KB and 86.4 TB a day up to 100 TB, and machine counts driven by RAM and disk IOPS.
2. Designing and Building Large-Scale Distributed Systems (Jeff Dean, LADIS 2009 keynote)cs.cornell.eduEstimating a design without building it, the 30-thumbnail back-of-the-envelope example, and designing for 10–20× growth.
3. napkin-math (Simon Eskildsen)github.comEstimation rules (few assumptions, keep the units, work in exponents) and the regional blob-storage price used in the cost estimate.
4. Payment System Indicators, September 2026 (Reserve Bank of India)rbi.org.inProvisional UPI volume (240,683.80 lakh) and value for September 2026, the starting point of the payments example; failed transactions excluded.
5. New Tweets per second record, and how! (Twitter Engineering, 2013, archived copy)web.archive.org500 million tweets a day (about 5,700 a second) against a 143,199-per-second peak, and 200–300 versus 10–20K requests a second per host.
6. Finding a Needle in Haystack: Facebook’s Photo Storage (Beaver et al., OSDI 2010)usenix.orgDaily uploads and views, 4 sizes × 3 copies = 12 writes per upload, and the share of photo reads absorbed before storage.
7. f4: Facebook’s Warm BLOB Storage System (Muralidhar et al., OSDI 2014)usenix.orgEffective replication factor of 3.6 versus 2.1 with erasure coding, and request rates that fall by an order of magnitude within a week.
8. Amazon DynamoDB Developer Guide: Best practices for designing partition keysdocs.aws.amazon.comPer-partition limits of 3,000 read units and 1,000 write units a second, used to count partitions.
9. Prefixes for binary multiples (NIST)physics.nist.govKiB versus KB: the IEC binary prefixes and why 2¹⁰ is not quite 10³.