Foundations: The Architect's Compass

What you'll learn

• Why System Design?

  System design interviews test your ability to design large-scale distributed systems. The key is to think about scalability, reliability, and performance.

• Interview Delivery Framework

  The most common failure mode: not delivering a working system. A structured approach provides a clear fallback path when overwhelmed.

• Step 1: Requirements (~5 min)

  Functional Requirements: - "Users/Clients should be able to..." statements - Engage in back-and-forth with interviewer (like speaking to a PM) - Arrive at top 3 core features — a long list hurts more than helps Non-functional Requirement…

• Step 2: Core Entities (~2 min)

  - List core entities as a simple bullet list - Helps define terms and understand central data - Don't list the full data model yet — build columns/fields later - Questions: Who are the actors? What nouns satisfy the requirements?

• Step 3: API / System Interface (~5 min)

  - Define the contract between system and users - Often maps directly to functional requirements - Sketch 4-5 key endpoints in a couple minutes and move on - Protocol: REST (default), GraphQL (diverse clients), gRPC (internal services) -…

• Step 4: High-Level Design (~10-15 min)

  - Draw boxes and arrows: components (servers, databases, caches) and interactions - Go through API endpoints one-by-one, building sequentially - Focus on simple design which first meets the core requirements - Note areas for future compl…

• Step 5: Deep Dives (~10 min)

  Use remaining time to: - Ensure non-functional requirements are met - Address edge cases — correctness holes: unusual inputs, races, or partial failures. The shape of the input breaks the design. Real examples: - Twitter/X celebrity post…

• Architecture Building Philosophy

  Two fundamental approaches exist for building a system's architecture in an interview or in practice:

• Spiral Building

  - What it is: Design the core component first — typically the database or communication protocol that best fits the use case — and build the entire system around that anchor. - When it works: You have deep experience and immediately reco…

• Incremental Building (Recommended for Interviews)

  - What it is: Start with a day-zero architecture (single server, single database) and evolve iteratively. - The loop: 1. Start with the simplest possible architecture. 2. Analyze how each component would behave under load and at scale. 3…

• The Six Foundation Pillars

  Every architectural decision in system design affects one of these six areas: | Pillar | What It Means | Example Decision | |--------|---------------|-----------------| | Database | Data storage and access patterns | SQL vs NoSQL, indexi…

• CAP Theorem — Practical Decision Guide

  Since network partitions are unavoidable, the real choice is Consistency vs Availability: | Choose | Behavior During Partition | Good For | |--------|--------------------------|----------| | AP (Availability) | Every node serves requests…

• Reliability, Durability, Availability, Resilience, Fault Tolerance — The "Five Pillars" of Trust

  CAP told you which two of {C, A, P} to keep. The Five Pillars answer a different question: when the system is running, how do we know it's actually doing its job — and what does "job" even mean here? Interviewers probe this because candi…

• The precise definitions (memorize the "measures" column)

  | Term | What it measures | Question it answers | Canonical example | |---|---|---|---| | Availability | Is the service reachable and responding right now? Uptime / total time. | "Can I hit the endpoint and get some response?" | 99.99% A…

• The wrong equations candidates default to

  Wrong: "Reliability = Availability + Durability." This is the most common trap and it fails on two obvious counterexamples: 1. Available + durable + unreliable. A banking API is 99.99% available and stores every transaction to a 3× repli…

• Can a system be highly reliable with LOW durability? Yes — and it's a common pattern

  The pasted claim "stateless microservices, in-memory caches, and real-time streaming can be highly reliable with low durability" is correct. The precise reason: their correctness contract doesn't require data survival past the current re…

• The hot-path / cold-path pattern (the leaderboard example, done right)

  Real-time multiplayer leaderboard, done as it's actually built at scale: Why individual score updates don't need "bulletproof" durability: 1. Self-correction. Every player's next action produces a new score. A lost update self-heals with…

• Where LOW reliability is deliberately acceptable in industry

  Not every system needs six nines. Over-engineering reliability is a real anti-pattern; it costs money, latency, and complexity that could have funded features. Common places where "low reliability, ship it" is the right call: 1. MVPs and…

• Derived metrics — MTBF, MTTR, RTO, RPO

  These are the levers you actually pull. They're derivatives of the Five Pillars, and they're what SRE conversations run on. | Metric | What it means | Formula / example | Which pillar it maps to | |---|---|---|---| | MTBF — Mean Time Bet…

• Where each pillar fails — the diagnostic table

  When someone reports "the system is broken," the first question is which pillar broke. They usually have different owners, different fixes, and different SEV levels. | Symptom | Likely broken R | Where to look first | Typical fix | |---|…

• Practical rule of thumb by workload type

  | Workload | Prioritize | Deprioritize | Because | |---|---|---|---| | Payment ledger | Durability, Reliability | Availability (accept slowdowns) | A missing charge is worse than a slow one | | Real-time chat | Availability, Resilience |…

• Key Technologies Quick Reference

  | Technology | Primary Use | When to Reach For It | |-----------|-------------|---------------------| | PostgreSQL | Transactional data, default DB | Most systems (start here) | | CockroachDB | Distributed SQL with ACID | Global consiste…