System Design Fundamentals

Theory

System design is the process of defining a system's architecture to meet functional requirements (what it does) and non-functional requirements (how well it does it — latency, availability, throughput, consistency). Every design decision is a trade-off: more consistency means less availability; more horizontal scaling means more operational complexity.

The design process starts with requirements clarification. Functional: what features must the system support? Non-functional: how many users, what read/write ratio, what latency target (p99 < 200ms?), what availability SLO (99.9% = 8.7h downtime/year, 99.99% = 52m/year)? Back-of-envelope estimation comes next: DAU × requests_per_user = QPS; QPS × data_per_request = storage growth rate.

The core building blocks appear in almost every system design: load balancers distribute traffic, application servers process requests, caches (Redis, Memcached) serve hot data, databases (SQL for ACID guarantees, NoSQL for horizontal scale) persist state, message queues (Kafka, SQS) decouple services, and CDNs serve static assets from edge nodes close to users.

CAP theorem (Brewer's theorem): a distributed system can only guarantee two of three properties simultaneously — Consistency (every read reflects the latest write), Availability (every request gets a response), and Partition tolerance (system works despite network splits). Since network partitions are unavoidable, systems choose CP (banks: correct data > availability) or AP (social feeds: available and eventually consistent).

Scalability approaches: vertical scaling (bigger machine — easier but has a ceiling), horizontal scaling (more machines — requires stateless services or distributed state). A stateless service stores no session data; any instance can handle any request. Stateful components (databases, caches with data) require consistent routing, leader election, or replication to scale horizontally.

Interview framework for "Design [System]": (1) Clarify requirements and scale, (2) Estimate capacity (QPS, storage, bandwidth), (3) Design API, (4) Define data model and schema, (5) Design high-level architecture, (6) Deep-dive the most critical/risky component, (7) Discuss trade-offs and what you'd change at 10×/100× scale. Interviewers evaluate depth of reasoning, not recall of a memorized answer.

Architecture Diagram

Requirements (scale, SLO, budget)
         |
  High-level components
         |
  Data flow + storage choice
         |
  Bottlenecks + failure modes
         |
  Trade-offs documented

Examples

10M DAU × 5 reads/day = 50M reads/day
≈ 580 reads/sec average, ~3k peak (5×)
Storage: 500B × 100M records ≈ 50GB + indexes

Interview Questions

Best Practices

• Treat System Design Fundamentals config as code with review and CI validation.
• Define SLOs and dashboards before production cutover.
• Document rollback and ownership for on-call.
• Use least privilege for credentials and secrets.

Common Mistakes

• Running System Design Fundamentals in prod without staging parity.
• No monitoring on golden signals after changes.
• Skipping backup/state export before major upgrades.
• Alert fatigue without actionable runbooks.

Trade-off Analysis

System Design Fundamentals improves requirements, cap, building blocks, design process. but adds operational and cognitive complexity — justify with load and team size.

Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.

Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.

Document accepted inconsistency windows and recovery behavior before production cutover.

Cheat Sheet

Practical Exercises