Module F-3·20 min read

QPS, storage, and bandwidth math built on real hardware numbers — sizing a system in five minutes without opening a spreadsheet.

JJS

Written by Jatin Jain Saraf · Senior Software Engineer

Module F-3 — Back-of-the-Envelope Estimation

Q: A team estimates 500,000 order confirmation emails per day and concludes the pipeline needs to handle "about 5 per second, so a single worker is plenty." The launch fails within minutes. What did the estimate miss?

The traffic shape. Confirmations are event-driven and bursty, so a promotional event can deliver a large share of the day's volume in minutes; the design must be sized for peak, with the average only useful for cost and storage estimates. — The module names "averaging away the peak" as the single most common estimation error, and puts event-driven or campaign-driven traffic in the 10–100× peak-factor bracket for exactly this reason — a push or campaign generates its entire load in about a minute. The arithmetic in option A is right and the conclusion drawn from it is wrong, which is the whole lesson: an average QPS figure describes cost and storage well and describes required capacity badly. Option C misassigns the peak factor; peaks are a throughput and capacity concern, while storage depends on daily totals and retention. Option B confuses a rounding convenience with the actual problem — using 10⁵ seconds/day changes the answer by 15%, not by the order of magnitude that caused the outage.

Q: A service writes 50 GB of new rows per day and the team plans for 90 days of retention, budgeting 4.5 TB of storage. Which multipliers does the module say are routinely omitted from this kind of figure?

Replication factor (typically 3×), index storage (often 30–100% of the table), WAL and backup retention, and soft-deleted rows that still occupy space — which together can turn 4.5 TB of logical data into several times that in paid storage. — The module gives storage as `writes × size × retention × replication × (1 + index & overhead)` and then lists the multipliers people forget every time: replication (your data exists three times), indexes that can rival the table on write-heavy schemas, the write-ahead log plus backup history, and soft deletes that keep "removed" rows on disk and in scans. Its stated conclusion is that a 1 TB logical database can easily occupy 3–4 TB of paid storage. Option B treats logical volume as physical volume, which is the error being described. Option C is real but incomplete and points the wrong way — the module's warning is about under-estimating. Option D applies a throughput concept to a storage calculation; peaks affect required capacity per second, not the daily accumulation.

Q: An estimate shows 6,000 QPS of read traffic at peak, and that a single Postgres primary handles roughly 5K–15K simple indexed reads per second. A cache is expected to absorb 90% of those reads. What does the module present as the correct conclusion?

With the cache, only ~600 QPS reach Postgres, so one primary plus a replica suffices — the cache specifically removes the need for a sharding project, at the cost of the staleness and invalidation problems it introduces. — The module works this exact comparison and draws exactly this conclusion, presenting it as the model for how an estimate should be used: not "caching is a best practice" but "this specific cache removes the need for this specific sharding project," with the cost named — the staleness and invalidation work of Modules P-12 and P-13. Option A ignores that 6,000 QPS sits at the lower end of a conservative range with no headroom for growth, spikes, or heavier queries, which is precisely the margin the cache buys. Option C overreacts; sharding is the response to a write bottleneck or a data-volume ceiling, and reaching for it here would be unpaid complexity. Option D contradicts the module's framing of the anchors as deliberately conservative order-of-magnitude figures, and its warning against precision theatre.

What this module covers: How to size a system in five minutes, on paper, and be confident you're within an order of magnitude. This module covers the handful of constants worth memorising, the four calculations that cover most designs (QPS, storage, bandwidth, working set), peak-vs-average as the trap that catches everyone, the multipliers people forget — replication, indexes, overhead — and the per-component sanity anchors that let you say "that needs about six servers" without opening a spreadsheet. Built on the real hardware numbers from Module F-2, so the answers mean something.

The Point Is to Reject Designs Cheaply

Estimation isn't about being right. It's about being right enough, fast enough to throw out bad designs before anyone builds them.

Three examples of what that looks like:

Someone proposes keeping all user sessions in a single Redis instance. Thirty seconds of arithmetic: 50M sessions × 2 KB = 100 GB. That doesn't fit the instance type anyone was imagining, so either the session object shrinks, the TTL shortens, or you're running a Redis cluster. Decision made, before the design doc got written.
Someone proposes a nightly full export to a partner. 400M rows × 1.2 KB = ~480 GB, over a pipe that does ~100 MB/s, is ~80 minutes of continuous transfer — assuming nothing else uses the link. That's not impossible, but it's an hour-and-a-half batch window with an egress bill attached, which is a different conversation from "we'll just add an export job."
Someone worries a proposed feature will overwhelm the database. 200K daily users × 3 actions = 600K writes/day, which is ~7 writes/second average and maybe 50/second at peak. A single Postgres handles that without noticing. No design change needed — and that's a valuable estimate too, because it prevents unnecessary complexity.

Notice all three took under a minute and none of them needed precision. Being off by 30% changes nothing. Being off by 100× changes everything, and back-of-the-envelope math reliably catches the 100× errors.

Analogy: estimation is the weight limit sign on a bridge, not a bathroom scale. Nobody needs to know a truck's mass to the gram. They need to know whether it's in the 5-tonne class or the 50-tonne class, because one of those crosses and one doesn't.

Why this matters in production: the estimates that fail are almost never wrong because someone mis-multiplied. They're wrong because a multiplier was missing — nobody counted replication, or index size, or the peak-to-average ratio, or the fact that every write also produces a WAL record, a replica copy, and a backup copy. The arithmetic is trivial. The discipline is in the checklist.

The Constants Worth Memorising

Time. There are 86,400 seconds in a day. Round it to 100,000 — it's a 15% error in the safe direction and it turns every division into moving a decimal point.

Quantity	Use
1 day ≈ 10⁵ seconds	daily total → QPS
1 month ≈ 2.6 × 10⁶ seconds	monthly totals, billing periods
1 year ≈ 3.2 × 10⁷ seconds	retention and growth

Sizes. Powers of two, rounded to powers of ten:

Unit	Bytes	Sanity anchor
1 KB	10³	a small JSON record, a tweet with metadata
1 MB	10⁶	a compressed photo, ~1,000 small records
1 GB	10⁹	a small table, a container's memory allowance
1 TB	10¹²	a healthy production Postgres
1 PB	10¹⁵	a data lake

Typical object sizes — worth having rough figures for, because storage estimates are only as good as these:

An integer or timestamp column: 4–8 bytes
A UUID: 16 bytes binary, 36 as text (a detail that matters at scale — Module P-3)
A short text row (user, order line, event): 100 B – 1 KB
A JSON API response: 1–10 KB
A compressed web image: 100 KB – 1 MB
A minute of 1080p video: ~50 MB

Latency, from Module F-2: memory ~100 ns, SSD read ~50 µs, same-datacentre round trip ~0.5 ms, cross-continent ~180 ms.

The Four Calculations

1. QPS: from users to requests per second

text

QPS(average) = DAU × actions per user per day ÷ 100,000
QPS(peak)    = QPS(average) × peak factor

The peak factor is where estimates live or die. Traffic is never flat — it follows waking hours, working hours, and events. Reasonable defaults:

Traffic shape	Peak factor	Example
Global consumer app, always-on	2–3×	messaging, social
Single-country consumer app	3–5×	domestic e-commerce, food delivery
Business-hours internal tool	5–10×	payroll, admin dashboards (idle 16 hours a day)
Event-driven or campaign-driven	10–100×	ticket sales, flash sales, push-notification fan-out

You must design for peak, not average. A system sized for average QPS is a system that falls over every day at 8pm. And the last row is not hyperbole: a push notification sent to two million users generates its entire load inside about a minute, which is why Module F-1's notification example concluded "queue it" before any code was written.

Worked example — a photo-sharing app:

text

10M DAU
Each user: 20 feed loads + 2 uploads per day

Feed reads:  10M × 20 ÷ 10⁵ = 2,000 QPS average → ×3 peak = 6,000 QPS
Uploads:     10M × 2  ÷ 10⁵ =   200 QPS average → ×3 peak =   600 QPS
Read:write ratio = 10:1 — read-heavy, so caching is the primary lever

That read/write ratio is one of Module F-1's four numbers, and it fell out of the estimate for free.

2. Storage: how much, and for how long

text

Storage/day = writes per day × bytes per write
Total       = Storage/day × retention days × replication factor × (1 + index & overhead)

Continuing the example:

text

Uploads:  10M × 2 = 20M photos/day
Photo:    ~500 KB average (after resizing/compression)
Metadata: ~1 KB per photo

Blob/day:     20M × 500 KB = 10 TB/day
Metadata/day: 20M × 1 KB   = 20 GB/day

Blobs, 3 years, 3 replicas:  10 TB × 1,000 days × 3  = 30 PB
Metadata, 3 years, 3 replicas + 50% index overhead:
  20 GB × 1,000 × 3 × 1.5 ≈ 90 TB

Two lessons land immediately. First, the blobs dwarf the metadata by ~300× — so blobs belong in object storage with lifecycle tiering (Modules A-11, O-8), and the database only holds pointers. Second, 30 PB is a number that changes the business model, not just the architecture; that's the estimate earning its keep before a line of code exists.

The multipliers people forget, every time:

Replication factor (usually 3). Your data exists three times. Module P-5.
Indexes. On a write-heavy table with several indexes, index storage can rival or exceed the table itself. Budget 30–100% on top.
The write-ahead log and backups. Every write is also a WAL record, and the backups retain history — so a 1 TB database can easily occupy 3–4 TB of paid storage across primary, replicas, WAL archive, and snapshots.
Soft deletes. deleted_at IS NOT NULL rows still occupy space and still get scanned. "We delete after 30 days" and "we mark deleted after 30 days" have very different storage curves.

3. Bandwidth: bytes per second in and out

text

Ingress = write QPS × bytes per write
Egress  = read QPS × bytes per response

text

Upload ingress (peak): 600 QPS × 500 KB  = 300 MB/s
Feed egress (peak):    6,000 QPS × 200 KB (10 thumbnails) = 1,200 MB/s = 1.2 GB/s

1.2 GB/s of egress is the single most important number in this whole estimate, for a reason that has nothing to do with capacity: egress bandwidth is one of the most expensive line items in cloud billing. At roughly $0.05–0.09/GB on major clouds, 1.2 GB/s sustained is on the order of $150K+/month if it all leaves the cloud provider's network directly. That is why a CDN in front of image traffic isn't a performance nicety, it's a financial requirement — CDN egress is cheaper per GB, and cache hits at the edge never touch your origin at all. Module F-15 covers the mechanism, Module O-8 the bill.

4. Working set: what has to fit in memory

The whole dataset doesn't need to be cacheable. The hot part does.

text

Working set ≈ (fraction of data accessed regularly) × total data
Cache size  ≈ working set × (1 + headroom)

Access in almost every real system is heavily skewed — a Zipf-like distribution where a small fraction of items absorbs most of the requests. As a starting assumption, 20% of the data serves 80% of the requests, and often it's far more extreme.

text

Feed metadata actively read: last 7 days ≈ 20 GB × 7 = 140 GB
Assume 20% is genuinely hot:  ~28 GB
Plus headroom and overhead:   ~40 GB of Redis

40 GB is a normal Redis footprint. 140 GB would have been an awkward one. The distinction between "the data" and "the working set" is the difference between a cache that's affordable and one that isn't — Module F-12 goes deeper, including how to measure the fraction rather than assume it.

Sanity Anchors: What One of Anything Handles

Estimates convert to infrastructure only if you know roughly what a single component does. These are deliberately conservative order-of-magnitude figures for commodity cloud hardware — they will be wrong for your workload, but not by 10×, and that's the point.

Component	Rough capacity per instance
Nginx / a reverse proxy, static or proxied	10K–50K req/s
Node.js app instance, trivial JSON	1K–5K req/s
Node.js app instance, one DB query per request	200–1,000 req/s
PostgreSQL primary, simple indexed reads (warm cache)	5K–15K QPS
PostgreSQL primary, writes with `fsync` on commit	1K–5K TPS
Redis, simple `GET`/`SET`, single instance	100K+ ops/s
Kafka broker, sequential append	100s of MB/s
One NVMe volume, random 4 KB reads	100K+ IOPS (Module F-2)

Applying them to the photo app:

text

Feed reads at peak: 6,000 QPS
→ App tier: 6,000 ÷ 500 req/s per instance = 12 instances, ×2 for headroom = ~24
→ DB: if the cache absorbs 90% of reads, only 600 QPS reach Postgres — one primary
  plus a replica handles it comfortably.
→ Without the cache: 6,000 QPS of feed queries against Postgres is at or past the
  limit of a single primary, and now you're discussing read replicas and sharding.

That last contrast is the entire argument for a cache layer, expressed in two lines of arithmetic. Not "caching is a best practice" — this specific cache removes the need for this specific sharding project. And the cost, named: everything Modules P-12 and P-13 cover about staleness and invalidation.

The Traps

Averaging away the peak. The single most common error. "600K writes a day is only 7 per second" is true and useless if 500K of them arrive in a five-minute window. Always ask what the traffic shape is.

Forgetting that reads and writes scale differently. Read load is absorbed by caches and replicas — comparatively easy. Write load hits the primary and is the thing that eventually forces sharding. When a design is described as "scaling to 10× traffic," check which kind.

Estimating steady state and ignoring the transition. A cache holding 40 GB is fine. Filling 40 GB after a deploy that flushed it means every request misses and goes to the database at once — the cold-start stampede of Module P-12. The steady state was affordable; the transition took the site down.

Counting only the happy path. Retries multiply request volume exactly when the system is least able to serve it. A client retrying three times turns a partial outage into 4× load — Module A-6's retry storm, and a reason peak factors should include a failure scenario, not just a traffic scenario.

Rounding in the same direction repeatedly. Round once, deliberately, in the conservative direction. If you round up at six steps you'll finish 3× over and stop trusting your own numbers.

Precision theatre. "We need 17.4 servers" is a worse answer than "about 20, call it 24 with headroom." Carrying two significant figures through an estimate built on ±50% assumptions creates false confidence and invites arguments about the wrong digit.

Where This Shows Up in Your Stack

Choosing an instance size: the working-set calculation tells you whether you need the 16 GB or the 64 GB Redis. Getting it wrong upward wastes money monthly; getting it wrong downward means eviction of hot keys and a hit-rate collapse that looks like a database problem.
PostgreSQL connection limits: max_connections × per-connection memory is a real ceiling, and the arithmetic behind "500 app instances × 10 connections each = 5,000 connections" is what makes Module P-4's pooling discussion inevitable rather than optional.
Vercel/Lambda cost modelling: invocations × average duration × memory is the entire billing formula. Estimating it before launch is how you avoid the "we shipped and the bill went up 40×" conversation — and it's the unit-economics thinking of Module O-8.
Interviews: estimation is scored explicitly. The signal isn't arithmetic, it's whether you use the result — "6,000 QPS against one Postgres won't work, so here's the cache, and here's what it costs me in staleness" is the answer being looked for.

Summary

Estimate to reject designs cheaply. Order of magnitude is enough; 100× errors are what you're hunting.
Memorise the constants: ~10⁵ seconds/day, KB/MB/GB/TB anchors, typical object sizes, and F-2's latency ladder.
QPS = DAU × actions ÷ 10⁵, then multiply by a peak factor of 2–3× (global consumer) up to 10–100× (event-driven). Design for peak.
Storage = writes × size × retention × replication × (1 + index overhead) — and the forgotten multipliers (replication, indexes, WAL, backups, soft deletes) are what make estimates wrong.
Bandwidth matters financially as much as technically. Egress is billed per GB; a CDN is often a cost decision first.
Size caches to the working set, not the dataset. A skewed access distribution is what makes caching affordable.
Know what one of each component handles so an estimate converts into a server count — and note when the answer is "no change needed," which is just as valuable.
Avoid the traps: averaged-away peaks, conflating read and write scaling, ignoring cold-start transitions, ignoring retries, compounded rounding, and false precision.

The next module, Latency, Throughput, and Tail Latency, sharpens the QPS-to-servers step. Averages are actively misleading at scale, and Little's Law turns "how many concurrent requests" into "how many servers" rigorously enough to argue with.

Knowledge Check

A team estimates 500,000 order confirmation emails per day and concludes the pipeline needs to handle "about 5 per second, so a single worker is plenty." The launch fails within minutes. What did the estimate miss?

A service writes 50 GB of new rows per day and the team plans for 90 days of retention, budgeting 4.5 TB of storage. Which multipliers does the module say are routinely omitted from this kind of figure?

An estimate shows 6,000 QPS of read traffic at peak, and that a single Postgres primary handles roughly 5K–15K simple indexed reads per second. A cache is expected to absorb 90% of those reads. What does the module present as the correct conclusion?

Test your knowledge with more question sets

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

PreviousModule F-2: Mechanical Sympathy: CPU Caches, Memory, and Disks Next Module F-4: Latency, Throughput, and Tail Latency

Discussion

Join the discussion

Loading comments...