Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)
The glossary lists terms and numbers; this companion gives the laws a senior is expected to derive on demand (Little's Law, Amdahl's, Gustafson's, the Universal Scalability Law, Moore's, Brooks's, Conway's, Metcalfe's, tail fan-out, the quorum caveat), the end-to-end capacity chain that ties numbers to a design, a quick capacity-anchors card, the consistency-model spectrum, and real definitions (with the fix) for the failure-mode vocabulary — so you can defend each under "but why?" pressure.
1. Little's Law: L = λ · W
In any stable system, the average number of items in the system L equals arrival rate λ times average time-in-system W. It's the #1 sizing tool. Thread-pool worked example: if you serve λ = 2000 req/s and each request occupies a worker for W = 50 ms = 0.05 s, then L = 2000 × 0.05 = 100 — you need ~100 concurrent workers (threads/connections) just to keep up, before any safety margin. Turn it around to find max throughput from a fixed pool: λ = L / W. It also sizes connection pools, in-flight buffers, and queue depths. No distribution assumed — it holds for any stable system.
2. The other laws every senior should know
| Law | What it says | Why it matters in system design |
|---|---|---|
| Amdahl's Law | Max speedup from N cores is bounded by the serial fraction s: Speedup ≤ 1 / (s + (1-s)/N). If 10% of the work is serial, the best possible speedup is ~10×, no matter how many cores you add. | Tells you when throwing hardware at a problem stops helping; identify and shrink the serial bottleneck first. |
| Gustafson's Law | If the problem size grows with N, scaled speedup can approach N: S = N - s(N-1). | Contrasts with Amdahl: when you can scale the workload (bigger data sets, more users), parallelism pays off even if the serial fraction is fixed. |
| Universal Scalability Law (Gunther) | C(N) = N / (1 + σ(N−1) + κN(N−1)): contention σ caps speedup exactly like Amdahl; the coherence/crosstalk term κN(N−1) makes throughput peak and then fall as N grows. Worked retrograde example (σ=0.05, κ=0.001): C(10) ≈ 6.49, C(50) ≈ 8.47, C(100) ≈ 6.31 — throughput at 100 nodes is below 50 nodes. | It is why a cluster can get slower when you add nodes: quorum chatter, cache invalidation, and lock coherence all grow ~N². Find σ/κ by fitting measured throughput at 3 fleet sizes; the retrograde region is traced in Latency vs Throughput. |
| Moore's Law | The number of transistors on a chip doubles roughly every two years; historically this meant single-thread performance grew predictably. | Single-core gains have slowed; modern scaling is horizontal (more machines), which is why distributed-systems literacy is now mandatory. |
| Brooks's Law | Adding people to a late software project makes it later because communication overhead grows as the team grows. | Explains why "just hire more engineers" does not linearly increase velocity; architecture and team boundaries must be designed together. |
| Conway's Law | Organizations design systems that mirror their own communication structures. | Use it deliberately: align team boundaries with service boundaries (bounded context) so the architecture and the org reinforce each other. |
| Metcalfe's Law | The value of a network is proportional to the square of its users (n² possible connections). | Explains network effects and viral growth; the flip side is that coordination and data-interdependence can also grow as n², so partition carefully. |
Trusted sources: Amdahl (1967), Gustafson (1988), Gunther Guerrilla Capacity Planning (2007), Moore (1965), Brooks The Mythical Man-Month (1975), Conway (1968), Metcalfe & the Ethernet-era formulation.
3. Tail-latency fan-out amplification
"Design for p99" isn't a slogan — it's arithmetic. A request that fans out to N backends and waits for all of them is fast only if every sub-call is fast: P(all fast) = (P_fast)^N. If each backend is fast 99% of the time, then at N=100 only 0.99^100 ≈ 37% of requests stay fast — 63% hit the tail. So a component's average latency is irrelevant to a wide fan-out; its p99 becomes the parent's typical latency. Defenses: minimize fan-out width, hedge/backup requests (take first of two), and set the SLO on p99, not the mean.
4. The quorum caveat: R + W > N is not linearizability
The cheat-sheet line "R + W > N ⇒ strong consistency" overstates it. R + W > N only guarantees the read set and write set overlap — a read touches at least one replica that saw the latest completed write. It does not give linearizability: two concurrent writes can still be accepted by different replica subsets and diverge (last-writer-wins clobbers one, or you get siblings) — the overlap says nothing about ordering concurrent operations. You need versioning + conflict resolution (vector clocks, LWW) or actual consensus (Raft/Paxos) for linearizability. Quote it as "quorum overlap ensures a read sees the last acknowledged write, not that concurrent writes are ordered."
5. The end-to-end capacity chain
Numbers only matter when chained to a decision: users → QPS → storage → shard/cache count. Worked: 10M DAU, each doing 20 actions/day → 200M actions/day ÷ 86,400 s ≈ 2,300 QPS average, ×~5 peak factor → ~12k QPS peak. If a shard sustains ~3k write QPS, you need ~4 shards for writes (+ replicas). Storage: 200M actions/day × 1 KB × 365 × 3 (replication) ≈ ~220 TB/yr → informs retention/tiering. Cache: if 90% hit ratio and a node holds the hot set, size the cache to the working set, not the whole dataset. The judgment is in the chain — each number forces the next design choice.
6. Capacity anchors — the numbers to know cold
| Anchor | Rule of thumb |
|---|---|
| Seconds in a day | ~86,400 ≈ 10⁵ (use 10⁵ for mental math) |
| 1 request/s | ≈ 100K/day ≈ 2.5M/month ≈ 30M/year |
| One app server | ~1K–10K simple QPS |
| Redis / in-memory store | ~100K ops/s |
| Postgres/MySQL simple reads | ~a few K – 50K QPS |
| SSD sequential | ~500 MB/s; 1 Gbps NIC = 125 MB/s |
| Latency ladder | L1 ~1 ns → RAM ~100 ns → SSD random ~100 µs → same-DC RTT ~0.5 ms → HDD seek ~10 ms → cross-continent ~150 ms |
| Availability | 99.9% ≈ 8.8 h/yr; 99.99% ≈ 52 min; 99.999% ≈ 5 min |
| Availability composition | Chain of dependencies: availability multiplies — two 99.9% hops in series = 99.8%. Redundancy: parallel replicas compose as 1 − (1−A)ⁿ — two 99% nodes = 99.99% (if failures are independent and failover works) |
| MTTF / MTBF / MTTR | MTTF = mean time to failure (how long a component runs before failing); MTBF = MTTF + MTTR. Availability = MTTF / (MTTF + MTTR) — the design goal is to repair much faster than things fail (MTTR ≪ MTTF) |
For the full drill card, see Numbers & Units You Must Know Cold.
7. Consistency models at a glance
| Model | Guarantee | When to think about it |
|---|---|---|
| Linearizable | Every operation appears to take effect atomically at some point between invocation and response; all observers see the same total order. | Bank balances, inventory, leader election — when stale reads are dangerous. |
| Sequential | Operations appear to execute in some global order consistent with each process's program order. | Formal reasoning; weaker than linearizable but still intuitive. |
| Causal | Causally related operations are ordered; concurrent operations may diverge. | Collaborative editors, comment threads, social feeds — users care about cause and effect. |
| Eventual | If updates stop, all replicas converge to the same value. | CDN caches, DNS, social like-counts — when staleness is acceptable. |
| Read-your-writes | A process always reads its own most recent writes. | User settings, posting then viewing — session-level guarantee. |
| Monotonic reads | If a process reads value v, later reads will not return values older than v. | Mobile clients refreshing a timeline — no time-travel. |
See also The Consistency Spectrum.
8. Failure-mode vocabulary (with the fix)
- Cache stampede / thundering herd — a hot key expires and all readers miss at once, hammering the origin. Fix: single-flight, stale-while-revalidate, or XFetch early expiry.
- Split-brain — a partition lets two sides both act as leader → divergent writes. Fix: quorum leadership + fencing tokens.
- Hot shard — one partition gets disproportionate load (skewed key). Fix: salt the hot key (pay read fan-out), or dedicated partition/cache for it.
- Retry storm — failures trigger retries that add load, causing more failures. Fix: exponential backoff + jitter, retry budgets, circuit breakers.
- Back-pressure — signalling a producer to slow when a consumer/buffer is saturated. Fix: bounded queues that block/shed, credit-based flow control.
- Circuit breaker — after N failures, stop calling a failing dependency (open) and fail fast, periodically probing (half-open) before closing. Fix pattern: protects you from cascading failure and gives the dependency room to recover.
- Cascading failure — a failing dependency overloads its callers, which fail and propagate load to their callers. Fix: timeouts, bulkheads, circuit breakers, graceful degradation.
- Network partition — nodes cannot communicate; CAP/PACELC forces a choice. Fix: decide in advance whether to be CP (quorum/fence) or AP (degrade/reconcile).
- Single point of failure (SPOF) — one component whose failure kills the whole system. Fix: redundancy, replication, failover, load-balancer pairs.
- Deadlock / livelock / starvation — concurrency pathologies where threads wait forever, spin forever, or are repeatedly skipped. Fix: lock ordering, timeouts, back-off, fair scheduling.
- Noisy neighbor — one tenant or workload starves others of a shared resource. Fix: quotas, rate limits, bulkheads, dedicated instances.
- Poison pill — a malformed message that crashes or stalls a consumer every time it is read. Fix: schema validation, DLQ, defensive parsing.
- Brownout — the system stays up but is too slow to be useful. Fix: load shedding, autoscaling, back-pressure, and SLO-driven alerting.
Takeaways
- Little's Law
L = λWsizes pools, queues, and connections — memorize it and the thread-pool derivation. - Amdahl's Law caps parallelism; Gustafson's Law says the cap loosens if the workload scales with cores; Gunther's USL adds the coherence term that makes throughput fall again at large N; Moore's Law explains why horizontal scale is now the default.
- Conway's and Brooks's laws are architecture tools: align teams with services, and don't expect headcount to rescue a late project.
- Tail fan-out:
(P_fast)^Ncollapses fast — a wide fan-out's typical latency is its children's p99, not their average. - Quorum
R+W>Ngives read/write overlap, not linearizability; concurrent writes still need versioning or consensus. - Chain numbers to decisions (users→QPS→storage→shards); a capacity number with no design consequence is noise.
- Know the consistency-model spectrum and the failure-mode vocabulary by name, so you can defend trade-offs in a design review.
Related pages: Capacity Estimation, Numbers & Units You Must Know Cold, System Design Building Blocks, Leader & Follower, Quorum, Caching.
When NOT to treat numbers as laws
- Jeff Dean numbers are order-of-magnitude anchors — measure your stack.
- When NOT to size only from averages — peaks and fan-out dominate.
Interviewer follow-ups & drills
- Little’s Law use? concurrency ≈ arrival rate × latency — size threads/pools from that.
- Drill: cross-region RTT ~100ms — how many sequential cross-region round trips fit in a 200ms budget? ~2. (A same-DC RTT of ~0.5ms would fit hundreds — which is why chatty cross-region call chains, not same-DC ones, blow the budget.)
Re-authored/Deepened for this guide. Laws and formulas are standard engineering references; see Amdahl (1967), Gustafson (1988), Gunther (2007), Moore (1965), Brooks (1975), Conway (1968), and Little (1961).
🤖 Don't fully get this? Learn it with Claude
Stuck on Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)** (System Design) and want to truly understand it. Explain Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive) 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.
Socratic — adapts to where you're stuck.
Teach me **Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)** 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.
Active recall exposes what you missed.
Quiz me on **Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)** 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.
Intuition + hook + flashcards for long-term memory.
Help me remember **Systems Cheat-Sheet — Laws, Numbers, Capacity Chain & Failure Modes (Deep Dive)** 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.