From Numbers to Architecture — Decision Gates

Estimation is only useful if it changes a decision

The point of the math is to trip a gate — a threshold where the design must change. Memorize these rough triggers; quoting them turns an estimate into an architectural argument.

If your estimate is…	…the design changes to
Write QPS > ~50K (or one primary saturates)	Shard / multiple primaries; partition by key
Read QPS ≫ write QPS (e.g. 100:1)	Cache + read replicas; precompute/fan-out
Cache working set > ~200–300 GB	Shard the cache (consistent hashing)
Storage in PB of immutable blobs	Object storage + CDN, not a database
Egress > a single NIC / tens of Gbps	CDN / edge serving
Strong consistency across regions needed	Consensus (Raft/Paxos) or accept higher latency (PACELC)
Spiky 10×+ peaks (flash sale)	Queue + autoscale + backpressure; don’t size for peak synchronously

The Hello-Interview principle

Don’t estimate for its own sake. Calculate the number that changes a decision — then state the gate it trips. “6K writes/s is fine on one primary; but reads at 600K/s force a cache layer” is the whole point.

Worked walkthrough — “Design a news feed”

1. Inputs: 100M DAU, 10 posts/day, ~500 B/post, 100:1 read:write.
2. QPS: writes ≈ 100M × 10 ÷ 86,400 ≈ 11.6K/s; reads ≈ 100 × that ≈ 1.16M/s.
3. Storage: 11.6K/s × 500 B × 86,400 × 365 ≈ ~180 TB/yr → shard; object-archive old media.
4. Bandwidth: 1.16M reads/s × ~2 KB ≈ ~2.3 GB/s → CDN for media, in-memory cache for metadata.
5. Gates tripped: reads ≫ writes and a >200 GB working set → cache + fan-out; nothing here forces multi-primary write sharding (11.6K writes/s fits one primary early).

Where each gate's number actually comes from

The thresholds above are not folklore — each is a capacity ceiling you can derive, and once derived it tells you not just whether the design changes but how many shards, nodes, or replicas you need.

The ~50K-writes/s single-primary gate → shard count

A single primary is bottlenecked on durable commits: every write must reach the write-ahead log and be fsync'd. A modern SSD sustains ~50–100K random-write IOPS, and group commit amortizes one fsync across a batch of transactions, so a well-tuned single primary sustains order 10⁴–10⁵ small-row commits/s before the single WAL/fsync stream saturates — take ~50K/s as the working ceiling. Read replicas do not raise it (they replay the same log); only a second independent WAL does. So the crossover is arithmetic: shards needed = ⌈required write QPS ÷ 50K⌉. At 200K writes/s that is ⌈200K / 50K⌉ = 4 shards, each owning a key range with its own WAL; aggregate write capacity then scales ~linearly at 50K/s per shard.

The ~200–300 GB cache gate → cache-node count

This gate is one machine's usable RAM. A large memory instance offers ~256 GB; you cap the cache's max memory at ~70% to leave room for fragmentation and background saves, giving ~180–200 GB usable per node. Larger instances (512 GB–1 TB) exist and stretch the gate toward 300 GB+, but fragmentation, fork-for-snapshot memory spikes, and the blast radius of losing one giant node argue for sharding at ~200 GB — treat the table's 200–300 GB as the argue-the-tradeoff band, not headroom. The working set itself follows hot-key skew: if 20% of keys serve 80% of traffic, you only cache the hot 20%, so working set ≈ 0.2 × total data. The gate therefore trips when 0.2 × total data > ~200 GB, i.e. total data > ~1 TB. Past it, cache nodes needed = ⌈working set ÷ 200 GB⌉ distributed with consistent hashing — a 1 TB working set → ⌈1000 / 200⌉ = 5 nodes.

The egress gate → why 2.3 GB/s already needs a CDN

A single server NIC is commonly 25 GbE; at the 70% utilization ceiling that is 25 × 0.7 = 17.5 Gbps of usable egress. The news-feed walkthrough above produced 1.16M reads/s × ~2 KB ≈ 2.32 GB/s, and 2.32 GB/s × 8 = 18.6 Gbps — already above one NIC's 17.5 Gbps usable. That single line is why the feed's media cannot be origin-served: one box physically cannot push the bytes, so you offload to a CDN/edge and keep the origin for cache-miss fills only.

Read replicas vs cache — the crossover that favors caching

“Reads ≫ writes” does not by itself say cache; the arithmetic does. A read replica serves on the order of ~50K reads/s, so 1.16M reads/s off replicas alone needs ⌈1.16M / 50K⌉ ≈ 24 replicas — every one a full copy of the data and its write stream. Put a cache in front at a 90% hit rate and only 10% of reads reach the database: 116K DB reads/s → ⌈116K / 50K⌉ ≈ 3 replicas behind the cache. Caching converts 24 replicas into ~3 replicas plus one cache tier — an order-of-magnitude fleet reduction, which is why the gate reads "cache + read replicas," cache first.

Now apply all of this in the drills below — estimate first, then reveal the worked solution and check your bounds.

---

Formulas are standard/public-domain engineering math. Approach and reference-table format adapted from the System Design Primer (CC BY 4.0), Jeff Dean’s latency numbers, the DesignGurus capacity-estimation guide, and Little’s Law.

I just read a lesson on **From Numbers to Architecture — Decision Gates** (System Design) and want to truly understand it. Explain From Numbers to Architecture — Decision Gates from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **From Numbers to Architecture — Decision Gates** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **From Numbers to Architecture — Decision Gates** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **From Numbers to Architecture — Decision Gates** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.