#🏗️ System Design Interview Preparation — Senior / Lead Engineer

Purpose: A comprehensive, structured repository for mastering system design interviews at FAANG+ companies.
Target Level: Senior Engineer (L5/E5) → Lead/Staff Engineer (L6/E6)
Approach: Each topic gets its own deep-dive document. You give a one-liner → we produce a full end-to-end design doc.

#📋 Table of Contents

How This Repository Works
Interview Framework — The FAANG Method
What Interviewers Actually Evaluate
The 45-Minute Blueprint
Question Framing — How FAANG Asks Questions
Answering Strategy — The Candidate's Playbook
Core Building Blocks Cheatsheet
Design Document Template
Cross-Cutting Notes & Concept Map
Topic Index — Design Deep-Dives

#🔄 How This Repository Works

You bring a one-liner (e.g. "Design YouTube")
         │
         ▼
┌─────────────────────────────────────┐
│  Interactive Clarification Round    │
│  (scope, constraints, priorities)   │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  Full Design Document Generated     │
│  ├── Requirements & Estimation      │
│  ├── HLD (Architecture + Diagrams)  │
│  ├── Deep-Dive on Core Components   │
│  ├── LLD (Data Models + APIs)       │
│  ├── Trade-offs & Decisions         │
│  └── Cross-references to other docs │
└─────────────────────────────────────┘

Every document follows the same structure so your brain builds muscle memory for the interview format.

#Folder Structure

system-design/
├── README.md                    ← You are here (master guide)
├── server.js                    ← Web UI Server
├── notes/
│   ├── concept-map.md           ← Central hub for all concepts
│   └── *.md                     ← High-level architectural theory
├── topics/
│   └── *.md                     ← End-to-end design problems
└── building-blocks/
    └── *.md                     ← Deep dives into specific technologies

#🛠️ Contributor Guidelines

STRICT RULE: Every design topic added MUST follow these guidelines to maintain repo integrity.

#1. File Structure

All design documents in topics/ must use the Design Document Template.

#2. Deep Linking Protocol

Concepts: Any mention of a major architectural pattern (e.g., Sharding, CQRS) must link to its respective file in notes/.
Technologies: Any mention of a specific technology (e.g., Redis, Kafka) must link to its file in building-blocks/.
Concept Map: After completing a design, update notes/concept-map.md with new cross-references.

#3. UI Friendliness

Use standard markdown.
For diagrams, use mermaid blocks or clear ASCII art.
Ensure tables are used for comparisons and trade-offs.

#4. Evolution-First Design

Always include a Scale Evolution section in the High-Level Design (HLD) to show how the system grows from MVP to FAANG-scale.


---

## 🎯 Interview Framework — The FAANG Method

### What Makes Senior/Lead Different from Mid-Level?

| Dimension | Mid-Level (L4) | Senior (L5) | Lead/Staff (L6+) |
|-----------|----------------|-------------|-------------------|
| **Scope** | Solves the stated problem | Identifies unstated requirements | Redefines the problem if needed |
| **Depth** | Picks reasonable components | Justifies every choice with trade-offs | Proposes alternatives and explains when each is better |
| **Breadth** | Designs the happy path | Handles edge cases and failure modes | Thinks about operational excellence, cost, and org impact |
| **Communication** | Answers questions | Drives the conversation | Treats interviewer as a collaborator, asks *them* questions |
| **Trade-offs** | Mentions trade-offs if asked | Proactively surfaces them | Frames decisions as "given constraint X, I chose Y because Z" |

### The Senior/Lead Mindset

> **You are not solving a puzzle. You are leading a design review.**

The interviewer is your peer engineer. Your job is to:
1. **Own the whiteboard** — Drive the discussion, don't wait for prompts
2. **Think out loud** — Your reasoning process IS the evaluation
3. **Be opinionated with humility** — "I'd choose X because... but if our constraint changes to Y, we'd pivot to Z"
4. **Prioritize ruthlessly** — You can't design everything in 45 min. Show you know what matters most.

---

## 🔍 What Interviewers Actually Evaluate

### The Scorecard (What's in the Interviewer's Rubric)

| Signal | Strong Hire Indicators | Red Flags |
|--------|----------------------|-----------|
| **Problem Exploration** | Asks clarifying questions that change the design; identifies hidden constraints | Jumps to solution immediately; accepts problem at face value |
| **High-Level Design** | Clean separation of concerns; identifies 3-5 core components; explains data flow | Monolithic blob; no clear boundaries; can't explain how components interact |
| **API Design** | RESTful / event-driven where appropriate; clear contracts; versioning awareness | Vague "API calls between services"; no concrete endpoints |
| **Data Model** | Schema matches access patterns; explains indexing; considers denormalization | Generic "put it in a database"; no thought about query patterns |
| **Scalability** | Calculates back-of-envelope numbers; scales specific bottlenecks, not everything | "Just add more servers"; premature optimization everywhere |
| **Trade-offs** | Every decision comes with "I chose X over Y because..."; revisits choices when scope changes | One-size-fits-all answers; "this is the best way" |
| **Operational Maturity** | Monitoring, alerting, deployment strategy, graceful degradation | Ignores failure modes; no mention of observability |

---

## ⏱️ The 45-Minute Blueprint

This is your time budget. Practice until this becomes instinctive.

┌─────────────────────────────────────────────────────────────────┐
│ 00:00 - 05:00 │ REQUIREMENTS & CLARIFICATION │
│ │ • Functional requirements (3-5 core features) │
│ │ • Non-functional requirements (latency, CAP) │
│ │ • Scale estimation (users, QPS, storage) │
├─────────────────────────────────────────────────────────────────┤
│ 05:00 - 10:00 │ BACK-OF-ENVELOPE ESTIMATION │
│ │ • DAU → QPS → Peak QPS │
│ │ • Storage per record → Total storage (5 yr) │
│ │ • Bandwidth, cache size estimates │
├─────────────────────────────────────────────────────────────────┤
│ 10:00 - 15:00 │ HIGH-LEVEL DESIGN │
│ │ • Core components on whiteboard │
│ │ • Data flow for primary use case │
│ │ • API contracts for key operations │
├─────────────────────────────────────────────────────────────────┤
│ 15:00 - 35:00 │ DEEP DIVE (The Make-or-Break Phase) │
│ │ • Database schema + access patterns │
│ │ • Scaling the bottleneck components │
│ │ • Caching strategy │
│ │ • Consistency vs Availability decisions │
│ │ • Failure handling and edge cases │
├─────────────────────────────────────────────────────────────────┤
│ 35:00 - 42:00 │ OPERATIONAL EXCELLENCE │
│ │ • Monitoring & alerting │
│ │ • Deployment strategy │
│ │ • Security considerations │
├─────────────────────────────────────────────────────────────────┤
│ 42:00 - 45:00 │ WRAP-UP & EXTENSIONS │
│ │ • Summarize key decisions │
│ │ • Mention what you'd add with more time │
│ │ • Open for interviewer's questions │
└─────────────────────────────────────────────────────────────────┘


---

## ❓ Question Framing — How FAANG Asks Questions

### The 4 Categories of System Design Questions

#### 1. Product Design Systems
> *"Design X"* — where X is a user-facing product  
> **Examples:** Design Twitter, Design Netflix, Design Google Docs  
> **What they test:** End-to-end thinking, product sense + engineering

#### 2. Infrastructure Systems
> *"Design a system that does X"* — lower-level infra  
> **Examples:** Design a Rate Limiter, Design a URL Shortener, Design a Task Scheduler  
> **What they test:** Algorithmic depth, distributed systems knowledge

#### 3. Data-Intensive Systems
> *"Design X that handles Y scale"* — focus on data pipeline  
> **Examples:** Design a Search Autocomplete, Design a News Feed, Design Analytics Platform  
> **What they test:** Data modeling, indexing, pipeline architecture

#### 4. Real-Time / Streaming Systems
> *"Design X with real-time requirements"*  
> **Examples:** Design a Chat System, Design Live Comments, Design a Collaborative Editor  
> **What they test:** WebSocket/SSE, event-driven architecture, consistency models

### How the Question Evolves During the Interview

Interviewer's Hidden Agenda:
┌─────────────┐ ┌────────────────┐ ┌───────────────────┐
│ Start Simple │ ──▶ │ Add Constraints │ ──▶ │ Break Your Design │
│ "Design X" │ │ "What if 10x │ │ "What happens when │
│ │ │ traffic?" │ │ this node fails?" │
└─────────────┘ └────────────────┘ └───────────────────┘


**Pro Tip:** Anticipate the follow-ups. When you make a design choice, preemptively say:  
*"This works at our current scale. If we 10x, I'd change this to..."*

---

## 🗣️ Answering Strategy — The Candidate's Playbook

### The RESHADE Framework (For Every Design Decision)

| Step | What You Say | Example |
|------|-------------|---------|
| **R**equirement | "The requirement here is..." | "We need sub-100ms read latency for the feed" |
| **E**valuate Options | "We could use A, B, or C..." | "Options: Fan-out-on-write, fan-out-on-read, hybrid" |
| **S**elect | "I'll go with B because..." | "Fan-out-on-write gives us O(1) reads at the cost of write amplification" |
| **H**ighlight Trade-off | "The trade-off is..." | "Celebrity users will cause write storms; we'll handle that separately" |
| **A**ddress Edge Cases | "Edge case: what if..." | "If a user has 10M followers, we switch to fan-out-on-read for them" |
| **D**efine Metrics | "We'd measure success by..." | "P99 feed load time < 200ms, fanout lag < 5s" |
| **E**xtend | "With more time, I'd also..." | "Add ML-based feed ranking, A/B testing framework" |

### Phrases That Signal Senior-Level Thinking

✅ "It depends on..." → Shows nuance
✅ "At our scale, this works because..." → Shows awareness of constraints
✅ "The trade-off here is X for Y..." → Shows engineering maturity
✅ "In production, we'd also need..." → Shows operational thinking
✅ "I've seen this pattern at..." → Shows experience (use sparingly)
✅ "Let me reconsider..." → Shows intellectual honesty

❌ "This is the best approach" → No approach is universally best
❌ "We'll just use Redis/Kafka" → Name-dropping without justification
❌ "I'm not sure, but..." → State your best reasoning confidently


### How to Handle "I Don't Know"

> **Never say "I don't know" and stop.** Instead:
> 1. State what you **do** know about the adjacent concept
> 2. Reason from first principles
> 3. Say: *"I haven't worked with X directly, but based on Y principle, I'd approach it as..."*

---

## 🧱 Core Building Blocks Cheatsheet

> These are the Lego pieces you'll assemble in every design. Know when and why to use each.

### Compute & Networking

| Component | When to Use | Key Consideration |
|-----------|-------------|-------------------|
| **Load Balancer** | Multiple server instances | L4 vs L7; round-robin vs least-connections vs consistent hashing |
| **API Gateway** | Microservices architecture | Rate limiting, auth, request routing, protocol translation |
| **CDN** | Static content, global users | Push vs Pull; cache invalidation; edge compute |
| **Reverse Proxy** | SSL termination, caching | Nginx vs HAProxy; connection pooling |

### Data Storage

| Component | When to Use | Key Consideration |
|-----------|-------------|-------------------|
| **SQL (PostgreSQL/MySQL)** | Structured data, ACID needed | Sharding strategy; read replicas; connection pooling |
| **NoSQL - Document (MongoDB)** | Flexible schema, hierarchical data | Denormalization strategy; eventual consistency |
| **NoSQL - Wide Column (Cassandra)** | High write throughput, time-series | Partition key design; compaction strategy |
| **NoSQL - Key-Value (Redis/DynamoDB)** | Simple lookups, caching, sessions | Eviction policy; persistence; cluster mode |
| **Search Engine (Elasticsearch)** | Full-text search, analytics | Index design; shard allocation; relevance tuning |
| **Graph DB (Neo4j)** | Relationship-heavy queries | Traversal patterns; vs SQL with recursive CTEs |
| **Object Storage (S3)** | Blobs, media files, backups | Lifecycle policies; multipart upload; pre-signed URLs |

### Messaging & Streaming

| Component | When to Use | Key Consideration |
|-----------|-------------|-------------------|
| **Message Queue (SQS/RabbitMQ)** | Async task processing, decoupling | At-least-once vs exactly-once; DLQ; ordering |
| **Event Streaming (Kafka)** | Event sourcing, high-throughput streams | Partition strategy; consumer groups; retention |
| **Pub/Sub (SNS/Google Pub/Sub)** | Fan-out notifications | Filtering; push vs pull subscriptions |

### Caching

| Strategy | Pattern | When to Use |
|----------|---------|-------------|
| **Cache-Aside** | App reads cache → miss → read DB → populate cache | General purpose; most common |
| **Write-Through** | App writes cache + DB together | Strong consistency needed |
| **Write-Behind** | App writes cache → async write DB | High write throughput; acceptable lag |
| **Read-Through** | Cache itself fetches from DB on miss | Simplifies app code; cache acts as proxy |

### Consistency & Coordination

| Concept | What It Solves | Options |
|---------|---------------|---------|
| **CAP Theorem** | Can't have all 3: Consistency, Availability, Partition Tolerance | CP (banking) vs AP (social media) |
| **Consensus** | Leader election, distributed locks | Raft, Paxos, ZooKeeper |
| **Idempotency** | Duplicate request handling | Idempotency keys, deduplication |
| **Distributed Transactions** | Cross-service data consistency | Saga pattern, 2PC (avoid if possible) |

---

## 📝 Design Document Template

> Every topic document in `topics/` follows this exact structure.

```markdown
# Design [System Name]

## 1. Problem Statement & Clarifications
### Functional Requirements (What the system does)
### Non-Functional Requirements (How well it does it)
### Out of Scope (What we're NOT designing)
### Assumptions

## 2. Back-of-Envelope Estimation
### Traffic Estimates
### Storage Estimates  
### Bandwidth Estimates
### Cache / Memory Estimates

## 3. API Design
### Core Endpoints / Interfaces
### Request/Response Contracts

## 4. Data Model
### Schema Design (SQL / NoSQL)
### Access Patterns
### Indexing Strategy

## 5. High-Level Design (HLD)
### Architecture Diagram
### Component Breakdown
### Data Flow (Write Path / Read Path)

## 6. Deep Dive — Core Components
### [Component 1] — Detailed Design
### [Component 2] — Detailed Design
### Scaling Strategy
### Caching Strategy
### Consistency Model

## 7. Low-Level Design (LLD) — Core Functionality
### Key Algorithms
### Design Patterns Used
### Class/Module Structure (Brief)

## 8. Failure Handling & Edge Cases
### What Happens When X Fails?
### Graceful Degradation
### Data Recovery

## 9. Monitoring & Observability
### Key Metrics
### Alerting Strategy
### SLAs / SLOs

## 10. Trade-off Summary
| Decision | Chose | Over | Because |
|----------|-------|------|---------|

## 11. Extensions & Follow-ups
### What Would You Add With More Time?
### How Would This Change at 100x Scale?

## 12. Cross-References
### Related Topics in This Repo
### Building Blocks Used

#🗺️ Cross-Cutting Notes & Concept Map

As we build topics, concepts will link to each other. This section grows over time.

#Concept Dependency Graph

                    ┌─────────────┐
                    │  CAP Theorem │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────────┐
        │Consistency│ │Availabil.│ │ Partition    │
        │ Models    │ │ Patterns │ │ Tolerance    │
        └─────┬────┘ └────┬─────┘ └──────┬───────┘
              │            │              │
              ▼            ▼              ▼
        ┌──────────┐ ┌──────────┐ ┌──────────────┐
        │  Strong  │ │  Circuit │ │  Replication  │
        │  vs      │ │  Breaker │ │  Strategies   │
        │  Eventual│ │  Pattern │ │               │
        └──────────┘ └──────────┘ └──────────────┘
              │                          │
              ▼                          ▼
        ┌──────────────────────────────────────┐
        │    Database Sharding & Partitioning   │
        └──────────────────────────────────────┘
              │
              ▼
        ┌──────────────────────────────────────┐
        │  Consistent Hashing (used by many)    │
        └──────────────────────────────────────┘

#Recurring Patterns Across Designs

Pattern	Where It Appears	Key Insight
Fan-out-on-write vs read	News Feed, Twitter, Notifications	Write amplification vs read latency trade-off
Consistent Hashing	Cache clusters, DB sharding, Load balancing	Minimizes redistribution on node add/remove
Event Sourcing	Chat, Collab Editor, Payment systems	Append-only log as source of truth
CQRS	E-commerce, Analytics, Search	Separate read/write models for optimization
Saga Pattern	E-commerce, Booking systems	Distributed transactions without 2PC
Bloom Filter	URL shortener, Web crawler, Dedup	Probabilistic "definitely not in set" check
Write-Ahead Log	Databases, Message queues, Any durable system	Crash recovery before committing
Lease-based Locks	Distributed coordination, Leader election	Time-bounded ownership to prevent deadlocks

#📚 Topic Index — Design Deep-Dives

Topics are added as we work through them. Each links to its own detailed document.

#🟢 Fundamentals (Start Here)

#	Topic	Document	Status
1	Design a URL Shortener	`topics/01-url-shortener.md`	⬜ Not Started
2	Design a Rate Limiter	`topics/02-rate-limiter.md`	⬜ Not Started
3	Design a Key-Value Store	`topics/03-key-value-store.md`	⬜ Not Started
4	Design a Unique ID Generator	`topics/04-unique-id-generator.md`	⬜ Not Started

#🟡 Product Systems

#	Topic	Document	Status
5	Design Twitter / News Feed	`topics/05-twitter-newsfeed.md`	⬜ Not Started
6	Design Instagram	`topics/06-instagram.md`	⬜ Not Started
7	Design YouTube / Netflix	`topics/07-video-streaming.md`	⬜ Not Started
8	Design WhatsApp / Chat System	`topics/08-chat-system.md`	⬜ Not Started
9	Design Google Drive / Dropbox	`topics/09-file-storage.md`	⬜ Not Started
10	Design Uber / Lyft	`topics/10-ride-sharing.md`	⬜ Not Started
11	Design Amazon / E-Commerce	`topics/11-ecommerce.md`	✅ Done

#🔴 Advanced / Infrastructure

#	Topic	Document	Status
12	Design a Web Crawler	`topics/12-web-crawler.md`	⬜ Not Started
13	Design a Notification System	`topics/13-notification-system.md`	⬜ Not Started
14	Design Search Autocomplete	`topics/14-search-autocomplete.md`	⬜ Not Started
15	Design a Distributed Cache	`topics/15-distributed-cache.md`	⬜ Not Started
16	Design a Task Scheduler	`topics/16-task-scheduler.md`	⬜ Not Started
17	Design Google Maps	`topics/17-maps-navigation.md`	⬜ Not Started
18	Design a Payment System	`topics/18-payment-system.md`	⬜ Not Started

#⚫ Expert-Level / Differentiators

#	Topic	Document	Status
19	Design Google Docs (Collab Editor)	`topics/19-collaborative-editor.md`	⬜ Not Started
20	Design a Distributed Message Queue	`topics/20-message-queue.md`	⬜ Not Started
21	Design a Metrics/Monitoring System	`topics/21-monitoring-system.md`	⬜ Not Started
22	Design a Distributed Consensus System	`topics/22-consensus-system.md`	⬜ Not Started

#🚀 How to Use This Repo for Prep

#Daily Routine (Recommended)

1. Pick one topic from the index
2. Set a 45-minute timer
3. Attempt the design on paper/whiteboard FIRST
4. Then read the deep-dive document
5. Note gaps in your approach
6. Review the cross-references to reinforce connected concepts

#Week Before the Interview

1. Review the Trade-off Summary tables across all topics
2. Practice the RESHADE framework on 2-3 random topics
3. Do a mock with a friend using the 45-Minute Blueprint
4. Review the Building Blocks Cheatsheet for quick recall

#📎 Quick Reference Links

Resource	Purpose
Building Blocks Reference	Component deep-dives
Concept Map	Cross-cutting concept connections
topics/	All design documents

Ready? Give me a one-liner and I'll generate the full design document. 🚀