Complete System Design Interview Guide — FAANG Level

The systematic approach to system design interviews. Learn the building blocks, then apply them to real case studies. This guide links 30+ deep-dive topics organized by concept, giving you a structured path from fundamentals to interview-ready confidence.

How to Use This Guide

The system design interview tests your ability to design large-scale distributed systems under time pressure (typically 35-45 minutes). Success requires two things: mastery of building blocks and a repeatable framework for structuring your answer.

Study path:

1. Learn the framework (next section) so you never freeze during an interview
2. Study Sections 1-5 to build your vocabulary of components and trade-offs
3. Practice Section 6 case studies to see how components combine into real systems
4. Use the preparation roadmap to plan your 4-6 week study schedule

Every link in this guide leads to a dedicated deep-dive page with diagrams, trade-off analysis, and interview-relevant details.

The System Design Interview Framework

Every system design question — from "Design a URL shortener" to "Design YouTube" — can be answered using this five-step framework. Interviewers expect this structure, and deviating from it is one of the most common reasons candidates fail.

Step 1: Clarify Requirements (3-5 minutes)

Never start drawing boxes immediately. Ask questions to scope the problem.

Functional requirements — What does the system do?

• Who are the users? How many?
• What are the core use cases? (List 3-5 max)
• What inputs/outputs does each API need?

Non-functional requirements — What qualities must the system have?

• Scale: How many DAU? Reads per second? Writes per second?
• Latency: What response time is acceptable? (p99 < 200ms?)
• Availability: Can we tolerate downtime? (99.9%? 99.99%?)
• Consistency: Is eventual consistency acceptable, or do we need strong consistency?
• Durability: Can we lose data? What's the retention policy?

Step 2: Back-of-Envelope Estimation (3-5 minutes)

Estimations show you understand scale and can make rational capacity decisions.

• Traffic: QPS for reads and writes
• Storage: How much data per record x number of records x retention period
• Bandwidth: QPS x average response size
• Memory: If caching, what percentage of data fits in RAM?

Link to: Estimation Cheatsheet — Reference numbers, formulas, and worked examples.

Step 3: High-Level Architecture (5-10 minutes)

Draw the major components and how data flows between them. Start simple:

• Client → Load Balancer → Application Servers → Database
• Add caches, queues, and CDNs as needed
• Identify read path vs. write path

Step 4: Component Deep Dive (10-15 minutes)

The interviewer will ask you to zoom into 1-2 components. Be ready to discuss:

• Database schema and indexing strategy
• API design (REST endpoints or RPC definitions)
• Data partitioning and replication strategy
• Caching layer design and invalidation policy
• How the system handles failures

Step 5: Trade-offs and Scaling (5-10 minutes)

Demonstrate maturity by discussing what you would do differently at 10x or 100x scale:

• Where are the bottlenecks?
• What are the single points of failure?
• What trade-offs did you make and why?
• How would you monitor and alert on this system?

1. Networking & Communication

What You Need to Know

Every distributed system relies on network communication between components. Understanding protocols, load distribution, and content delivery is foundational. You should be able to explain the difference between L4 and L7 load balancing, when to use WebSockets vs. polling, and how a CDN reduces latency for global users.

Key questions interviewers ask:

• How does HTTPS prevent man-in-the-middle attacks?
• When would you use a reverse proxy vs. a load balancer?
• How do you push real-time updates to millions of connected clients?

Go Deeper

• HTTPS & TLS — TLS handshake, certificate chains, and how secure communication works end-to-end
• WebSockets & SSE — Real-time communication patterns, connection management at scale
• Load Balancers — L4 vs L7 balancing, algorithms (round-robin, least connections, consistent hashing), health checks
• Proxies — Forward proxy vs. reverse proxy, use cases, and how they fit into system architecture
• CDN — Content delivery networks, push vs. pull invalidation, edge caching strategies
• API Gateway — Request routing, rate limiting, authentication, and protocol translation

2. Data Storage & Databases

Core Principles

Database choice is often the most consequential decision in a system design. You need to understand when relational databases excel (ACID transactions, complex joins, strong consistency) vs. when NoSQL is the right fit (flexible schema, horizontal scaling, high write throughput).

Key principles:

• ACID guarantees in relational databases (Atomicity, Consistency, Isolation, Durability)
• BASE semantics in NoSQL systems (Basically Available, Soft state, Eventually consistent)
• Indexing dramatically improves read performance but slows writes
• Denormalization trades storage for read speed — common in read-heavy systems
• Write-ahead logs (WAL) ensure durability before acknowledging writes

Further Reading

• SQL vs NoSQL — Decision framework for choosing between relational and non-relational databases
• CAP Theorem — Why you must choose between consistency and availability during network partitions
• Database Sharding — Horizontal partitioning strategies, shard key selection, resharding challenges
• Data Partitioning — Range partitioning, hash partitioning, list partitioning, and composite approaches
• Replication — Leader-follower, multi-leader, and leaderless replication with conflict resolution
• Consistent Hashing — Ring-based distribution that minimizes data movement when nodes join or leave

3. Caching & Performance

Strategies & Trade-offs

Caching is the single most impactful technique for reducing latency and database load. A well-designed cache can reduce p99 latency from 100ms to under 5ms. However, caching introduces complexity around invalidation, consistency, and memory management.

Cache strategies you must know:

• Cache-aside (Lazy loading): Application checks cache first, loads from DB on miss
• Write-through: Write to cache and DB simultaneously
• Write-behind (Write-back): Write to cache immediately, asynchronously persist to DB
• Read-through: Cache itself loads data from DB on miss

Invalidation approaches:

• TTL-based: Simple but can serve stale data
• Event-driven: Invalidate on write — fresher but more complex
• Versioning: Append version to cache key — avoids race conditions

Cache eviction policies: LRU (most common), LFU, FIFO, Random

Reference Pages

• Distributed Caching — Cache topologies, consistency challenges, thundering herd prevention
• Redis — Data structures (strings, hashes, sorted sets, streams), clustering, persistence modes
• Bloom Filters — Space-efficient probabilistic membership testing, false positive rates
• Rate Limiting — Token bucket, sliding window log, sliding window counter, and distributed rate limiting

4. Distributed Systems Concepts

Failure Modes & Guarantees

Distributed systems introduce failure modes that don't exist in single-machine applications. Networks can partition, clocks can drift, nodes can crash silently, and messages can arrive out of order. Understanding these challenges — and the algorithms designed to handle them — separates senior engineers from juniors in interviews.

Fundamental challenges:

• Network partitions: Nodes cannot communicate; must decide whether to remain available or preserve consistency
• Clock skew: Different machines have different clock values; cannot rely on timestamps for ordering
• Split brain: Multiple nodes believe they are the leader simultaneously
• Byzantine failures: Nodes may behave arbitrarily (though most interview questions assume crash-stop failures)

Key guarantees to discuss:

• Exactly-once delivery: Extremely hard; most systems achieve at-least-once with idempotency
• Linearizability: Strongest consistency — every operation appears to happen at a single point in time
• Causal consistency: Operations that are causally related appear in order; concurrent operations may be reordered

Study These Topics

• Consensus Algorithms — Paxos and Raft: how distributed nodes agree on a single value despite failures
• Leader Election — Bully algorithm, ring algorithm, ZooKeeper-based election
• Distributed Transactions — Two-phase commit (2PC), three-phase commit, and the Saga pattern
• Distributed Locks — Redlock algorithm, ZooKeeper recipes, fencing tokens for correctness
• Heartbeat & Gossip — Failure detection protocols, phi-accrual detector, epidemic protocols
• Service Discovery — Client-side vs. server-side discovery, DNS-based, registry-based (Consul, etcd)
• Circuit Breakers — Preventing cascading failures, states (closed/open/half-open), timeout tuning

5. Design Building Blocks

Essential Components

Beyond the core distributed systems theory, certain components appear in nearly every system design answer. Message queues enable asynchronous processing, decouple producers from consumers, and absorb traffic spikes. Unique ID generation is required whenever you need to identify entities across a distributed system without coordination.

When to introduce a message queue:

• Work can be processed asynchronously (email sending, image processing)
• You need to decouple services (order service shouldn't wait for inventory service)
• You need to absorb write spikes (queue buffers requests, workers process at their own pace)
• You need guaranteed delivery with retry semantics

ID generation requirements in distributed systems:

• Globally unique without coordination between nodes
• Roughly time-sortable (enables range queries on creation time)
• Compact enough for URLs or database keys
• High throughput (thousands of IDs per second per node)

Deep Dives

• Message Queues — Kafka vs. RabbitMQ, delivery semantics, partitioning, consumer groups, dead letter queues
• Unique ID Generation — UUID, Twitter Snowflake, ULID, database sequences, and trade-offs between approaches

6. Case Studies — Practice Problems

These are full system design walkthroughs following the five-step framework. Each page covers requirements, estimation, high-level design, deep dives, and trade-offs for a commonly asked interview question.

How to practice:

1. Set a 35-minute timer
2. Open the problem without looking at the solution
3. Write out your answer following the framework
4. Compare against the walkthrough
5. Identify gaps in your knowledge and revisit the relevant deep-dive page

Interview Preparation Roadmap

A structured 6-week plan for system design interview preparation, assuming 1-2 hours of study per day.

Tips for each week:

• Week 1-3: Focus on understanding, not memorization. Draw diagrams. Explain concepts out loud.
• Week 4-5: Practice under time pressure. You should be able to produce a coherent design in 35 minutes.
• Week 6: Focus on communication. The best candidates narrate their thinking process clearly.

Quick Recall — System Design Concepts

Use this table for rapid review before interviews. Each concept is distilled to its essential one-line definition.

Common Mistakes in System Design Interviews

Avoid these pitfalls that consistently cause candidates to receive "no hire" decisions:

1. Diving into details without clarifying requirements. Starting to draw databases and caches before understanding the problem scope signals that you cannot manage ambiguity. Always spend 3-5 minutes asking clarifying questions.

2. Ignoring back-of-envelope estimation. If you design a system that stores 100 TB in a single PostgreSQL instance, the interviewer will question your practical experience. Quick math prevents obviously infeasible designs.

3. Designing for Google scale from the start. Not every system needs 10 million QPS. Start with a simple design that works, then scale iteratively. Over-engineering at the start wastes precious interview time.

4. Not discussing trade-offs. Every design decision has a cost. If you choose eventual consistency, acknowledge that users may see stale data. If you add a cache, discuss invalidation complexity. Interviewers reward nuanced thinking.

5. Using buzzwords without understanding. Saying "we'll use Kafka" without explaining why (ordering guarantees, consumer groups, retention) or when a simpler queue would suffice suggests superficial knowledge.

6. Neglecting failure scenarios. What happens when a node crashes? When the network partitions? When the database is unavailable? Production systems must handle failures gracefully, and your design should address this.

7. Forgetting about data consistency. In distributed systems, data can become inconsistent across replicas or services. You must explicitly state your consistency model and explain how you handle conflicts.

8. Poor time management. Spending 20 minutes on database schema leaves no time for the interesting distributed systems discussion. Practice with a timer to develop pacing intuition.

9. Not considering monitoring and observability. Production systems need metrics, logging, and alerting. Mentioning how you'd monitor your system (latency percentiles, error rates, queue depths) demonstrates operational maturity.

10. Presenting a single solution without alternatives. Senior engineers evaluate multiple approaches before choosing one. Briefly mention alternatives you considered and why you rejected them — this demonstrates breadth of knowledge.

Behavioral Tips for System Design Interviews

Beyond technical knowledge, how you communicate matters significantly:

• Think out loud. The interviewer is evaluating your thought process, not just the final diagram. Narrate your reasoning as you make decisions.
• Drive the conversation. Don't wait for the interviewer to ask "what about caching?" Proactively introduce components and explain why they're needed.
• Use concrete numbers. Instead of "this will be fast," say "with a Redis cache, p99 latency drops from 50ms to 2ms for cached queries."
• Draw clear diagrams. Label every arrow with the protocol or data flowing through it. Use boxes for services, cylinders for databases, and clouds for external systems.
• Acknowledge unknowns. If you're unsure about something, say "I'm not certain about the exact threshold, but my approach would be..." Honesty is valued over bluffing.
• Summarize periodically. After completing a section, briefly recap what you've covered. This helps the interviewer follow your design and signals structured thinking.

Recommended Study Resources

• "Designing Data-Intensive Applications" by Martin Kleppmann — The definitive book on distributed systems concepts. Chapters 5-9 are especially relevant.
• "System Design Interview" by Alex Xu (Vol 1 & 2) — Practical walkthrough of common interview questions with diagrams.
• MIT 6.824: Distributed Systems — Lecture videos covering Raft, MapReduce, and fault tolerance with academic rigor.
• The Google SRE Book (free online) — Real-world operational concerns: monitoring, incident response, capacity planning.
• RFC documents — Reading RFCs for protocols you mention (HTTP/2, gRPC, WebSocket) demonstrates deep understanding.

Frequently Asked Questions

Company-Wise Topics: What Gets Asked Where

See Also

• Microservices Architecture — Decomposition patterns, service communication, and operational concerns
• API Design — REST principles, versioning, pagination, and error handling
• GraphQL — Query language for APIs, schema design, and when to prefer over REST
• Spring Boot WebFlux — Reactive programming for high-throughput services