Foundations
The mental model and shared vocabulary every system-design interview assumes you already have. Frameworks, abstractions, consistency, failure modes, capacity math.
These pages are the prerequisites — the toolkit you can't assemble on the spot during a 45-minute interview. Spend the most time on the 7-step walk-through (it's the scaffold every later design hangs on) and on the capacity-estimation cheatsheet (it's the math you'll do reflexively).
The consistency-models and failure-models pages turn fuzzy 'what could go wrong' anxiety into a small set of named scenarios you can reason about explicitly. Most failed interviews fail here — not in the high-level design.
Key concepts
- Anchor every design on the same 7-step structure — clarify, estimate, contract, high-level, data, detail, evaluate
- Numbers to know cold: memory access ~100 ns, SSD read ~150 µs, cross-region RTT ~150 ms, 1 GB/s = 8 Gbps
- Consistency is a spectrum, not a switch — pick the weakest model that satisfies your invariants
- Failure models are layered: assume crash-recovery for nodes, omission for the network, never Byzantine unless asked
- Estimation is rounding-friendly: order-of-magnitude beats precision when interviewers care about the reasoning
Reference template
// The 7-step system-design walk-through
1. Clarify Requirements (functional + non-functional; ask, don't assume)
2. Capacity Estimation (QPS, storage, bandwidth — order-of-magnitude)
3. System Interface (API contract — endpoints, payloads, idempotency)
4. High-Level Design (boxes + arrows; major services and data flow)
5. Data Model (schemas, partitioning key, hot-row analysis)
6. Detailed Design (zoom into 2-3 components the interviewer cares about)
7. Evaluation & Trade-offs (bottlenecks, alternatives, what you'd push back on)Adapt to your problem; the structure is the load-bearing part.
Common pitfalls
- Jumping to high-level design before clarifying — produces a confident answer to the wrong problem
- Quoting capacity numbers without showing the back-of-envelope work the interviewer wants to see
- Defaulting to 'strong consistency' for everything — most user-facing reads tolerate seconds of staleness
- Treating CAP as a 3-way choice during a network partition (it isn't — you only pick between C and A *during* the partition)
Related topics
Items (8)
- The 7-Step System-Design Walk-Through
A repeatable interview framework — clarify, estimate, contract, high-level, data, detail, evaluate. Read this first; every system writeup on this site follows it.
Concept Foundational - Abstractions in Distributed Systems
What an interviewer means when they say 'service', 'node', 'cluster' — the unit boundaries that shape every design.
Concept Foundational - Remote Procedure Calls (RPC)
Network abstractions over function-call semantics: gRPC, Thrift, REST-as-RPC, the leaks they hide and don't.
Concept Foundational - Consistency Models
From strong to eventual: linearizability, sequential, causal, monotonic, eventual — what each costs and what each buys.
Concept Intermediate - Failure Models
Crash-stop, crash-recovery, omission, Byzantine — the assumption stack under every fault-tolerance claim.
Concept Intermediate - Capacity Estimation Cheatsheet
Latencies, throughputs, sizes, and conversion shortcuts to keep in your head for back-of-envelope math.
Concept Foundational - Resource Estimation — Worked Examples
Four end-to-end estimation walk-throughs (Twitter, YouTube, WhatsApp, a search index) — the math anchored to the Foundations cheatsheet.
Concept Foundational - Interview Frameworks Compared
8-step, 4-step, SNAKE, PACELC-flavored — what each emphasizes and which to anchor on under pressure.
Concept Foundational