Worked examples of the QPS, storage, and bandwidth math every HLD interview expects — converting daily active users into numbers that actually justify architecture decisions.
Published September 23, 2026
HLD Fundamentals Refresher names "Estimation" as step 2 of the 5-step framework — this lesson is the actual worked math, because "I'd do back-of-envelope math" without producing real numbers doesn't demonstrate the skill an interviewer is checking for.
Given: 10 million daily active users (DAU), each makes 20 requests/day on average
Total requests/day = 10,000,000 × 20 = 200,000,000
Average QPS = 200,000,000 / 86,400 seconds ≈ 2,315 QPS
Peak QPS (traffic isn't uniform — assume 3x average at peak hours):
Peak QPS ≈ 2,315 × 3 ≈ 6,945 QPS
The peak-vs-average distinction matters: a system designed only for average QPS will fall over during genuinely normal peak-hour traffic. A standard, defensible assumption (stated explicitly, not silently assumed) is 2-3x average as a peak multiplier unless the problem states something more specific (e.g. a ticket-sale system with a single sharp spike might need a much higher multiplier).
Given: 10 million DAU, each posts 2 items/day averaging 1 KB of text + occasionally a 200 KB image
(assume 20% of posts include an image)
Text storage/day = 10,000,000 × 2 × 1 KB = 20,000,000 KB ≈ 19 GB/day
Image storage/day = 10,000,000 × 2 × 0.20 × 200 KB = 800,000,000 KB ≈ 763 GB/day
Total/day ≈ 782 GB/day
Over 5 years: 782 GB × 365 × 5 ≈ 1.4 PB
This single calculation already justifies a real architecture decision: at ~1.4 PB over 5 years, storing images directly in a relational database is clearly wrong — this is exactly the number that justifies routing images to object storage (S3-equivalent) with only a reference URL stored in the database, rather than a design decision made on instinct alone.
Incoming bandwidth = requests/sec × average request size
≈ 2,315 QPS × 1 KB ≈ 2.3 MB/s incoming
Outgoing bandwidth (reads typically dominate, e.g. 10:1 read:write ratio)
≈ 23,150 reads/sec × 5 KB average response ≈ 116 MB/s outgoing
Bandwidth estimates matter for choosing CDN strategy, provisioning network capacity, and sanity-checking whether a proposed design's read path (often the higher-bandwidth side, given typical read-heavy workloads) needs a caching layer at all — a back-of-envelope bandwidth number that comes out surprisingly high is itself a signal to add caching before the design is finished, not after a prototype reveals the problem.
A 100:1 read:write ratio (typical for a social feed) argues strongly for:
— aggressive caching (Caching Strategies) on the read path
— read replicas for the database (writes go to primary, reads spread across replicas)
— potentially a denormalized read model optimized purely for read speed
A close-to-1:1 read:write ratio (e.g. a chat message system) argues against
over-investing in read-side caching relative to write-path throughput
Stating the read:write ratio explicitly — and then deriving architecture choices FROM it — is what separates estimation-informed design from estimation as decoration. A design that adds heavy caching for a write-heavy workload (or skips caching for an overwhelmingly read-heavy one) reads as not having actually used its own numbers.
Q: How precise do these numbers need to be — is it a problem if the real answer is off by 2x? A: No — the point of back-of-envelope math is establishing the right ORDER OF MAGNITUDE (thousands of QPS vs millions, gigabytes vs petabytes) to justify a class of architecture decision, not precise capacity planning; being off by a factor of 2-3x rarely changes which architecture pattern is appropriate, being off by 100x usually would.
Q: What if the interviewer doesn't give explicit numbers like DAU or average request size? A: State reasonable, explicit assumptions out loud ("I'll assume 10 million DAU for a service at this scale") rather than silently picking a number — an interviewer can correct an explicitly stated assumption easily; a silently assumed one just produces confusing downstream numbers if it's wrong.
Q: Should estimation be redone after the deep-dive reveals more detail? A: Often yes for the specific component being deep-dived — e.g. discovering during a caching deep-dive that cache hit rate is expected to be 95% lets you recalculate the ACTUAL database QPS (5% of total, not 100%), a materially more useful number than the original undifferentiated estimate.
Q: Is memory estimation for a cache layer done the same way as storage estimation? A: Same method, different assumption — instead of estimating ALL data, estimate the WORKING SET (the subset of data actually accessed frequently enough to be worth caching, often a small fraction of total data per typical access-pattern skew), since provisioning cache memory for 100% of total storage is usually neither necessary nor economical.