1.1 What You Need Before Starting

System design sits at the intersection of computer science, software engineering, and product thinking. You do not need a PhD, but you do need comfort with certain primitives. Think of it like learning to navigate the open ocean: you don't need to build the boat on day one, but you must understand tides, compass headings, and how sails catch wind.

1.2 Networking Fundamentals

Every distributed system is, at its core, computers talking to each other over a network. When you design a chat app, a payment gateway, or a video streaming platform, you are really designing who talks to whom, over what protocol, with what latency budget, and what happens when the message never arrives.

Key Concepts You Must Internalize

1.3 Database Fundamentals

Data is the treasure buried on every island in your architecture. Choosing where and how to store it determines consistency, scalability, and operational complexity. At a foundation level, understand the two great families of databases and their trade-offs.

The ACID vs BASE Mental Model

ACID (Atomicity, Consistency, Isolation, Durability) guarantees that database transactions behave predictably — critical for banking. BASE (Basically Available, Soft state, Eventually consistent) accepts temporary inconsistency in exchange for availability and partition tolerance — common in globally distributed systems. You'll revisit this deeply when we cover CAP theorem in Module 13.

-- Foundational SQL you'll encounter in LLD discussions
CREATE TABLE users (
  id         BIGSERIAL PRIMARY KEY,
  email      VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_users_email ON users(email);
-- Indexes are the "table of contents" — trade write speed for read speed

1.4 Computer Science Building Blocks

These concepts appear in every system design discussion. You don't need to implement a B-tree from scratch, but you must speak fluently about them when justifying design decisions.

1.5 Environment & Tooling Setup

Hands-on practice reinforces theory. Set up a lightweight environment for sketching architectures, running local services, and experimenting with APIs.

# Recommended baseline tooling
# macOS (Homebrew)
brew install git node python@3.12 docker

# Verify installations
git --version && node --version && python3 --version && docker --version

# Optional: run local Redis + PostgreSQL via Docker
docker run -d --name local-redis -p 6379:6379 redis:7-alpine
docker run -d --name local-postgres -e POSTGRES_PASSWORD=dev \
  -p 5432:5432 postgres:16-alpine

curl -X GET https://api.github.com/users/octocat
curl -X POST https://httpbin.org/post -H "Content-Type: application/json" \
  -d '{"message": "hello from system design course"}'

1.6 How to Use This Masterclass

1. Read sequentially first. Modules build on each other. Skipping to "Design Twitter" without understanding caching is like sailing without charts.
2. Sketch as you read. Redraw every diagram from memory on paper or Excalidraw. Active recall beats passive reading 10:1.
3. Complete every quiz. Each module ends with MCQs designed to surface gaps in understanding. Read explanations even for questions you got right.
4. Time-box deep dives. Aim for 15–20 minutes per module section, 5 minutes per quiz. The full course targets 5–6 hours.
5. Revisit case studies. Modules 16–18 apply everything. Return to them after completing the theory modules.

2.1 What Is System Design?

System design is the process of defining the architecture, components, modules, interfaces, and data flows for a software system to satisfy specified requirements. It answers: "Given a problem like 'build Instagram' or 'process 1 million payments per hour,' how do we decompose it into reliable, scalable, maintainable pieces?"

It is not coding. It is not picking React vs Vue. It is the engineering decision-making layer that sits above individual features — deciding how services communicate, where state lives, what fails gracefully, and what trade-offs you accept.

2.2 High-Level Design vs Low-Level Design

The single most important distinction in this entire course. Confusing HLD with LLD is like confusing a city zoning map with a building's floor plan — both are "design," but they operate at different zoom levels.

2.3 Functional vs Non-Functional Requirements

Every system design session begins with requirements. Splitting them correctly prevents you from over-engineering features nobody asked for while ignoring the constraints that actually break production systems.

2.4 The Structured Design Process

Senior engineers don't freestyle. They follow a repeatable framework that ensures nothing critical is missed. Internalize this 7-step process — you'll use it in every case study module.

Step 2 in Action: Back-of-the-Envelope Math

Estimation separates senior engineers from junior ones. You don't need exact numbers — you need the right order of magnitude.

Example: URL Shortener scale estimation
─────────────────────────────────────
Assumptions:
  • 100M new URLs/month
  • Read:Write ratio = 100:1
  • Average URL stored = 500 bytes
  • Retention = 5 years

Writes/sec  = 100M / (30 × 24 × 3600) ≈ 40 writes/sec
Reads/sec   = 40 × 100 = 4,000 reads/sec
Storage     = 100M × 12 × 5 × 500B = 3 TB (raw, before replication)

→ Reads dominate → aggressive caching (Redis) is essential
→ Writes are modest → single DB shard may suffice initially
→ 3 TB is manageable → no exotic storage needed yet

2.5 Trade-offs — The Core Skill

There is no perfect architecture — only trade-offs aligned with requirements. System design is less about finding the "right answer" and more about articulating why you chose A over B given constraints C and D.

When you propose a design, always pair it with: "I'm choosing X because [requirement]. The trade-off is Y, which we mitigate by Z." This sentence structure alone elevates interview performance dramatically.

2.6 Architectural Styles Preview

Before diving into individual patterns in later modules, orient yourself to the three dominant architectural styles. We'll explore each in depth in Module 4.

3.1 Why Requirements Come First

A system designed for 100 users looks nothing like one designed for 100 million. A banking ledger demands different consistency guarantees than a social media "like" counter. Requirements are the contract between problem and solution — miss them, and you optimize for the wrong thing entirely.

3.2 Functional Requirements — The Feature Contract

Functional requirements describe what the system must do. They should be specific, testable, and unambiguous. Vague requirements like "the system should be fast" are NFRs in disguise — functional requirements name concrete behaviors.

Writing Testable Functional Requirements

User Stories vs Use Cases

User stories (Agile): "As a [role], I want [feature], so that [benefit]." Great for prioritization. Use cases: step-by-step interaction flows including edge cases and alternate paths. Great for design completeness. In system design interviews, narrate use cases aloud while the interviewer nods or redirects.

Use Case: Create Short URL
─────────────────────────
Actor:     Registered user
Precond:   User is authenticated
Main flow:
  1. User submits long URL
  2. System validates URL format
  3. System generates unique 7-char code
  4. System persists mapping
  5. System returns short URL
Alt flow 3a: User provides custom alias → check uniqueness
Alt flow 4a: DB unavailable → return 503, do not return broken link

3.3 Non-Functional Requirements — The Quality Taxonomy

NFRs are where system design lives. They are often under-specified in interviews on purpose — the interviewer wants to see you ask the right clarifying questions. Memorize this taxonomy:

3.4 Constraints — The Boundaries You Cannot Cross

Constraints are hard limits. Unlike NFRs (which are targets you optimize toward), constraints are immovable walls. Ignoring them invalidates your entire design.

3.5 Scope Management — MoSCoW Prioritization

Not every requirement ships in v1. MoSCoW prevents scope creep and forces explicit prioritization — critical in interviews when the interviewer says "we have 45 minutes."

In interviews, state your assumptions: "I'll treat analytics as a Should Have and focus the core design on redirect latency and scale." This shows product thinking and time management.

3.6 The Clarification Question Bank

Memorize and adapt these questions. Ask 5–8 at the start of any design session. The answers reshape your entire architecture.

SCALE
  • How many daily active users (DAU)? Total registered users?
  • Read-to-write ratio?
  • Expected growth rate (6 months, 1 year)?
  • Peak vs average traffic (burst factor)?

PERFORMANCE
  • Latency targets (p50, p99)?
  • Throughput (requests/sec)?
  • Real-time vs batch acceptable?

DATA
  • How much data stored per entity?
  • Retention period?
  • Consistency requirements (strong vs eventual)?
  • Can we lose data? Under what conditions?

USERS & GEO
  • Global or single region?
  • Mobile, web, or both?
  • Authenticated vs anonymous users?

CONSTRAINTS
  • Existing tech stack or greenfield?
  • Budget / team size / timeline?
  • Regulatory requirements (GDPR, HIPAA)?

4.1 Anatomy of a Good HLD Diagram

A strong HLD diagram answers four questions at a glance: Who calls whom? Where does data live? What are the failure points? How does traffic scale? It uses consistent notation, labels protocols on arrows, and groups related components.

4.2 Monolith vs Microservices vs Serverless

The most common architectural decision. There is no universal winner — only the right fit for your team's size, scale, and operational maturity.

4.3 Layered (N-Tier) Architecture

The classic pattern: separate presentation, business logic, and data access into distinct layers. Each layer only talks to the layer directly below it. Simple, well-understood, and still the backbone of most enterprise applications.

When to use: CRUD-heavy business apps, internal tools, e-commerce backends. Watch out for: the "anemic domain model" where the logic layer becomes a thin pass-through — keep business rules in the business layer, not scattered in controllers.

4.4 Event-Driven Architecture (EDA)

Instead of services calling each other directly (tight coupling), producers emit events to a message broker. Consumers subscribe and react independently. This enables loose coupling, async processing, and natural audit trails.

Benefits: decoupling, resilience (consumers can retry), scalability (add consumers without changing producer). Costs: eventual consistency, debugging complexity, need for idempotent consumers.

4.5 Data Flow & Component Interaction

Every HLD must show read path and write path separately — they often have different performance characteristics and caching strategies.

Read Path (URL Shortener redirect):
  Client → CDN edge → Load Balancer → API Server → Redis cache (hit?) → return 301
                                              ↓ miss
                                         PostgreSQL read replica → populate cache → return 301

Write Path (create short URL):
  Client → Load Balancer → API Server → generate code → PostgreSQL primary (write)
                                                    → async replicate to read replicas
                                                    → optionally warm Redis cache

4.6 Choosing Your Architecture Style

Use this decision flowchart mentally during interviews:

5.1 REST API Design Principles

REST (Representational State Transfer) models your system as resources identified by URLs, manipulated via HTTP verbs. Good REST APIs are predictable, cacheable, and self-describing.

Resource-Oriented URL Design (URL Shortener)
────────────────────────────────────────────
POST   /api/v1/urls              Create short URL       → 201 Created
GET    /api/v1/urls/{code}       Get URL metadata       → 200 OK
GET    /api/v1/urls/{code}/stats Get click analytics    → 200 OK
DELETE /api/v1/urls/{code}       Deactivate short URL   → 204 No Content

GET    /{code}                   Redirect (not /api/)   → 301 Moved Permanently

Anti-patterns to avoid:
  POST /api/createShortUrl       (verb in URL — use nouns)
  GET  /api/deleteUrl?id=123     (mutation via GET — never)
  GET  /api/v1/getAllUsers       (RPC style disguised as REST)

HTTP Status Codes You Must Know

5.2 REST vs gRPC vs GraphQL

Three dominant API paradigms — each optimized for different constraints. Choosing the wrong one creates friction for years.

5.3 Synchronous vs Asynchronous Communication

Synchronous: caller waits for response (HTTP request/response). Simple mental model, but creates temporal coupling — if the callee is slow or down, the caller suffers. Asynchronous: caller sends message and continues (queue/event). Decouples availability but introduces complexity (ordering, duplicates, eventual consistency).

5.4 Idempotency, Retries & Rate Limiting

Distributed systems fail mid-request. Networks drop packets. Clients retry. Without idempotency, a payment API called twice charges the customer twice.

Idempotent operations produce the same result no matter how many times they're executed. GET, PUT, DELETE are naturally idempotent. POST is not — solve with Idempotency-Key headers stored in Redis with TTL.

// Client sends idempotency key on POST
POST /api/v1/payments
Headers: Idempotency-Key: "550e8400-e29b-41d4-a716-446655440000"

// Server logic:
if (redis.exists(idempotency_key)) {
  return cached_response;  // duplicate — return same result
}
result = process_payment(request);
redis.setex(idempotency_key, 86400, result);
return result;

// Rate limiting (Token Bucket algorithm)
// 100 requests/minute per API key → return 429 when exceeded
// Headers: X-RateLimit-Remaining: 42, X-RateLimit-Reset: 1620000000

5.5 API Versioning & Documentation

APIs evolve. Versioning strategy prevents breaking existing clients. Common approaches:

• • URL versioning: /api/v1/users — simple, explicit, most common
• • Header versioning: Accept: application/vnd.myapi.v2+json — clean URLs, harder to test in browser
• • Query param: /api/users?version=2 — least recommended

Document APIs with OpenAPI (Swagger) specs — they generate interactive docs, client SDKs, and mock servers. In system design interviews, listing 3–4 key endpoints with request/response shapes demonstrates API thinking without writing full specs.

6.1 Entity-Relationship Modeling

Before picking a database, model your entities (nouns: User, Order, URL) and relationships (verbs: places, contains, maps-to). This ER diagram drives your schema regardless of SQL or NoSQL.

-- Relational schema derived from ER diagram
CREATE TABLE short_urls (
  id          BIGSERIAL PRIMARY KEY,
  code        VARCHAR(10) UNIQUE NOT NULL,
  long_url    TEXT NOT NULL,
  user_id     BIGINT REFERENCES users(id),
  created_at  TIMESTAMPTZ DEFAULT NOW(),
  expires_at  TIMESTAMPTZ,
  is_active   BOOLEAN DEFAULT TRUE
);
CREATE INDEX idx_short_urls_code ON short_urls(code);      -- redirect lookup
CREATE INDEX idx_short_urls_user ON short_urls(user_id);   -- user's URLs list

6.2 Normalization vs Denormalization

Normalization eliminates redundancy — data lives in one place (3NF). Updates are consistent but reads may require JOINs. Denormalization duplicates data for faster reads — common in read-heavy systems at scale.

6.3 SQL vs NoSQL — Decision Framework

6.4 Sharding & Partitioning

When a single database node can't hold your data or serve your query load, you partition (split) data across multiple nodes. Horizontal partitioning (sharding) splits rows by a shard key. Vertical partitioning splits columns or tables by feature.

Shard key selection is critical — a bad key (e.g., country) creates hot shards. Good keys distribute evenly (user_id hash, UUID). Avoid cross-shard JOINs — design queries to hit a single shard.

6.5 Data Access Patterns Drive Everything

The single most important database design principle: design your schema around how data is read and written, not around how it looks on a whiteboard.

7.1 Why Caching Exists — The Memory Hierarchy at Scale

You learned in Module 1 that CPU cache is 100× faster than RAM, which is 1000× faster than disk. Distributed systems follow the same principle: **keep hot data as close to the consumer as possible**. Every cache layer trades freshness for speed.

7.2 Core Caching Patterns

Four fundamental patterns govern how application code interacts with cache and database. Know all four — interviews often ask you to pick one and justify it.

// Cache-Aside pseudocode (URL redirect)
function getLongUrl(shortCode):
  cached = redis.get("url:" + shortCode)
  if cached:
    return cached                          // cache HIT (~1ms)

  row = db.query("SELECT long_url FROM short_urls WHERE code = ?", shortCode)
  if row:
    redis.setex("url:" + shortCode, 3600, row.long_url)  // TTL 1 hour
  return row.long_url                      // cache MISS (~10ms)

7.3 CDN Caching — Edge Proximity

A Content Delivery Network (CDN) caches static and dynamic content at edge servers geographically close to users. A user in Tokyo hits a Tokyo edge node instead of your US-origin server — slashing latency from 300ms to 20ms.

Cache-Control headers control CDN behavior: max-age=3600 (cache 1 hour), no-cache (revalidate every time), private (browser only, not CDN). For URL shortener redirects, CDN can cache 301 responses for popular short codes.

7.4 Eviction Policies & TTL

Caches have finite memory. When full, something must go. TTL (Time To Live) expires entries automatically. Eviction policies decide what to remove when memory is full.

TTL strategy: Short TTL (60s) for frequently changing data. Long TTL (24h) for static content. Jitter TTL (random ±10%) to prevent synchronized mass expiration.

7.5 Cache Invalidation — The Hard Problem

Phil Karlton famously said: "There are only two hard things in Computer Science: cache invalidation and naming things." When source data changes, stale cache entries must be updated or removed.

// Write-invalidate on URL update
function updateLongUrl(shortCode, newUrl):
  db.execute("UPDATE short_urls SET long_url = ? WHERE code = ?", newUrl, shortCode)
  redis.del("url:" + shortCode)   // invalidate — next read refreshes cache

7.6 Thundering Herd & Cache Stampede

When a popular cache key expires, thousands of concurrent requests all miss simultaneously and hammer the database — a cache stampede. Mitigations:

• • Mutex / lock: Only one request rebuilds cache; others wait or return stale
• • Probabilistic early expiration: Randomly refresh before TTL expires
• • Never expire hot keys: Background refresh before expiration
• • Request coalescing: Deduplicate in-flight requests for same key

8.1 Vertical vs Horizontal Scaling

Vertical scaling (scale up): add more CPU/RAM to one machine. Simple but has a ceiling — the biggest cloud instance costs 10× more for 2× performance. Horizontal scaling (scale out): add more machines. The path to internet scale, but requires load balancing and stateless design.

8.2 Layer 4 vs Layer 7 Load Balancing

8.3 Load Balancing Algorithms

8.4 Stateless Servers & Session Affinity

For true horizontal scaling, application servers must be stateless — any server can handle any request. Session data lives in Redis, not server memory. When state is unavoidable, sticky sessions (session affinity) route the same user to the same server — but this complicates scaling and failover.

8.5 Health Checks & Auto-Scaling

Load balancers continuously health check backends — HTTP GET /health every 10s. Unhealthy servers are removed from rotation automatically. Auto-scaling groups add/remove servers based on CPU, request count, or custom metrics — paying only for capacity you need.

Auto-scaling policy example:
  Scale OUT when: avg CPU > 70% for 3 minutes
  Scale IN  when: avg CPU < 30% for 10 minutes
  Min instances: 2  |  Max instances: 20  |  Desired: 4

Health check endpoint:
  GET /health → 200 { "status": "ok", "db": "connected", "redis": "connected" }

9.1 Why Message Queues?

Without queues, every operation is synchronous — the user waits for email sending, image resizing, and analytics logging before seeing "Order Placed." Queues let you acknowledge fast and process slow.

• • Decoupling: producer doesn't know about consumers
• • Buffering: absorb traffic spikes without overwhelming downstream
• • Reliability: messages persist if consumer is temporarily down
• • Scalability: add more consumers to process faster

9.2 Delivery Guarantees

The hardest problem in messaging: ensuring messages are processed exactly once in a world where networks fail and consumers crash. In practice, you choose a guarantee and design idempotent consumers.

9.3 Kafka vs RabbitMQ vs SQS

9.4 Dead Letter Queues & Backpressure

When a message fails processing repeatedly (poison message), it moves to a Dead Letter Queue (DLQ) for manual inspection — preventing infinite retry loops that block the queue.

Backpressure occurs when consumers can't keep up with producers. Solutions: scale consumers, throttle producers, increase queue capacity, or shed load (drop low-priority messages).

// Idempotent consumer pattern
function processOrderEvent(event):
  if redis.setnx("processed:" + event.id, 1, ttl=86400):
    charge_payment(event)
    send_confirmation_email(event)
  else:
    log("Duplicate event, skipping")  // safe to ignore

9.5 Event Sourcing Preview

Instead of storing current state, event sourcing stores every state change as an immutable event log. Current state is reconstructed by replaying events. Kafka's commit log is naturally suited for this pattern — we'll see it applied in case studies.

10.1 HLD to LLD — The Zoom-In Transition

After HLD defines the URL Shortener's boxes (API Server, Redis, PostgreSQL), LLD zooms into the API Server box and asks: What classes exist? What methods do they expose? How does encoding work? What exceptions are thrown?

10.2 SOLID Principles

SOLID guides maintainable object-oriented design. Internalize these — interviewers probe them in LLD rounds.

10.3 Sequence Diagrams — Object Interactions Over Time

Sequence diagrams show who calls whom, in what order, over time. Essential for LLD interviews when explaining a use case flow.

10.4 LLD Code Structure — Layered Implementation

// Interface (Dependency Inversion)
interface UrlRepository {
  save(url: ShortUrl): ShortUrl
  findByCode(code: string): ShortUrl | null
  existsByCode(code: string): boolean
}

// Service layer (business logic)
class UrlService {
  constructor(
    private repo: UrlRepository,
    private encoder: UrlEncoder,
    private cache: CacheClient
  ) {}

  async createShortUrl(longUrl: string, userId?: string): Promise<ShortUrl> {
    this.validateUrl(longUrl)
    const code = await this.generateUniqueCode()
    const url = new ShortUrl(code, longUrl, userId)
    const saved = await this.repo.save(url)
    await this.cache.set(`url:${code}`, longUrl, 3600)
    return saved
  }

  private async generateUniqueCode(): Promise<string> {
    // retry loop with collision detection
  }
}

10.5 LLD Interview Approach

1. Clarify scope: "Are we designing the full system or one component?"
2. Identify entities: nouns become classes (User, Order, ParkingSpot)
3. Define relationships: associations, inheritance, composition
4. Walk through use cases: draw sequence diagrams for 2–3 main flows
5. Handle edge cases: concurrency, validation, error handling
6. Discuss extensibility: how would you add feature X without rewriting?

11.1 What Are Design Patterns?

A design pattern is a proven template for structuring classes and their interactions. Patterns are not copy-paste code — they are a shared vocabulary. Saying "I'll use Strategy for payment methods" instantly communicates intent to any experienced engineer.

11.2 Creational Patterns

Singleton — One Instance Only

Guarantees a class has exactly one instance with global access. Use for database connection pools, configuration managers, thread pools. Caution: overuse creates hidden dependencies and makes testing hard.

class DatabaseConnectionPool {
  private static instance: DatabaseConnectionPool
  private constructor() {}  // prevent direct instantiation

  static getInstance(): DatabaseConnectionPool {
    if (!DatabaseConnectionPool.instance) {
      DatabaseConnectionPool.instance = new DatabaseConnectionPool()
    }
    return DatabaseConnectionPool.instance
  }
}

Factory / Factory Method — Delegate Object Creation

Encapsulates object creation logic. Client asks for a "Notification" without knowing if it's Email, SMS, or Push. Classic LLD example: Design a Notification System.

interface Notification { send(message: string, recipient: string): void }

class EmailNotification implements Notification { /* ... */ }
class SmsNotification implements Notification { /* ... */ }
class PushNotification implements Notification { /* ... */ }

class NotificationFactory {
  static create(type: 'email' | 'sms' | 'push'): Notification {
    switch (type) {
      case 'email': return new EmailNotification()
      case 'sms':   return new SmsNotification()
      case 'push':  return new PushNotification()
    }
  }
}

Builder — Construct Complex Objects Step by Step

When an object has many optional fields (Order with items, discounts, shipping, gift wrap). Builder provides fluent API and validates before construction.

const order = new OrderBuilder()
  .setCustomer(userId)
  .addItem(productId, quantity)
  .applyCoupon('SAVE10')
  .setShippingAddress(address)
  .build()  // validates all required fields before creating Order

11.3 Structural Patterns

Adapter — Bridge Incompatible Interfaces

Wraps a legacy or third-party API so it conforms to your interface. Your payment system expects PaymentProcessor; Stripe SDK has a different API — Adapter bridges the gap.

Decorator — Add Behavior Without Subclassing

Wraps an object to add responsibilities dynamically. A base Coffee can be wrapped with MilkDecorator, then WhipDecorator. In systems: add logging, caching, or encryption layers around a service.

Facade — Simplified Interface to Complex Subsystem

OrderFacade.placeOrder() internally coordinates inventory, payment, shipping, and notification services — client sees one simple method.

Proxy — Stand-In With Controlled Access

Proxy controls access to a real object. Use cases: lazy loading (load image only when displayed), access control, remote proxy (RPC stub), caching proxy.

11.4 Behavioral Patterns — The LLD Workhorses

Strategy — Swap Algorithms at Runtime

Define a family of algorithms, encapsulate each, and make them interchangeable. The #1 pattern in LLD interviews.

// Parking Lot LLD — different pricing strategies
interface PricingStrategy {
  calculateFee(entryTime: Date, exitTime: Date): number
}

class HourlyPricing implements PricingStrategy { /* $5/hour */ }
class FlatRatePricing implements PricingStrategy { /* $20/day */ }
class WeekendPricing implements PricingStrategy { /* 1.5× multiplier */ }

class ParkingTicket {
  constructor(private strategy: PricingStrategy) {}
  getFee(entry: Date, exit: Date) { return this.strategy.calculateFee(entry, exit) }
}

Observer — Publish/Subscribe Within Code

When one object's state change must notify many dependents. OrderSubject notifies EmailObserver, InventoryObserver, AnalyticsObserver on order placement. Mirrors event-driven architecture at the code level.

Command — Encapsulate Actions as Objects

Turn requests into objects with execute() and undo(). Powers undo/redo in text editors, job queues, and transaction systems. Each command stores the receiver and parameters.

State — Behavior Changes With Internal State

Object behavior changes when its state changes. A VendingMachine behaves differently in Idle, HasMoney, Dispensing, and OutOfStock states — each state is its own class implementing a common interface.

interface VendingState {
  insertCoin(machine: VendingMachine): void
  selectProduct(machine: VendingMachine, code: string): void
  dispense(machine: VendingMachine): void
}

class IdleState implements VendingState {
  insertCoin(m) { m.setState(new HasMoneyState()); m.addCredit(1) }
  selectProduct(m, code) { throw new Error("Insert coin first") }
  dispense(m) { throw new Error("No product selected") }
}

11.5 Pattern Selection Guide for LLD Interviews

11.6 Anti-Patterns to Avoid

• • God Object: one class does everything — violates SRP, untestable
• • Pattern overload: forcing Factory + Strategy + Decorator + Observer into a simple CRUD app
• • Premature abstraction: "We might need 10 payment methods someday" — YAGNI applies
• • Singleton abuse: global mutable state makes unit testing a nightmare
• • Inheritance over composition: deep class hierarchies break Liskov; favor interfaces + composition

12.1 Concurrency vs Parallelism

Concurrency is about dealing with many things at once — structuring your program so multiple tasks make progress. Parallelism is about doing many things at once — literally executing on multiple CPU cores simultaneously. You can have concurrency without parallelism (single-core time-slicing) and parallelism without much concurrency (embarrassingly parallel batch jobs).

12.2 Race Conditions & Critical Sections

A race condition occurs when the correctness of your program depends on the unpredictable timing of thread execution. The classic example: two threads increment a shared counter — both read 0, both write 1, result is 1 instead of 2.

// RACE CONDITION — counter may be less than 1000
let counter = 0

// Thread A and Thread B both run this:
counter = counter + 1   // NOT atomic! Read → increment → write = 3 steps

// After 1000 increments from 2 threads, counter might be 847, not 1000

A critical section is the code region that accesses shared resources. Only one thread may execute the critical section at a time — protected by synchronization primitives.

12.3 Synchronization Primitives

// Mutex-protected counter — thread safe
mutex = new Mutex()
counter = 0

function increment():
  mutex.lock()
  try:
    counter = counter + 1    // critical section — only one thread here
  finally:
    mutex.unlock()

// Semaphore — limit concurrent DB connections to 10
dbSemaphore = new Semaphore(10)

function queryDatabase(sql):
  dbSemaphore.acquire()
  try:
    return db.execute(sql)
  finally:
    dbSemaphore.release()

12.4 Deadlock — When Threads Wait Forever

A deadlock occurs when two or more threads are blocked forever, each waiting for a resource held by another. All four Coffman conditions must be true simultaneously:

1. Mutual exclusion — resource held by only one thread at a time
2. Hold and wait — thread holds one resource while waiting for another
3. No preemption — resources can't be forcibly taken away
4. Circular wait — A waits for B, B waits for A

Deadlock Prevention Strategies

• • Lock ordering: always acquire Lock 1 before Lock 2 — breaks circular wait
• • Lock timeout: tryLock(timeout) — abort and retry instead of waiting forever
• • Minimize lock scope: hold locks for the shortest time possible
• • Avoid nested locks: redesign to need only one lock

12.5 Thread-Safe Design Patterns

// Producer-Consumer with blocking queue (thread-safe by design)
queue = new BlockingQueue<Task>(capacity=100)

// Producer thread
function producer():
  while running:
    task = generateTask()
    queue.put(task)          // blocks if queue full (backpressure)

// Consumer threads (pool of N workers)
function consumer():
  while running:
    task = queue.take()      // blocks if queue empty
    process(task)

12.6 Concurrency in LLD & System Design

In LLD interviews, concurrency appears in parking lots (multiple entry/exit gates), elevators (multiple requests), ticket booking (seat reservation races), and rate limiters. Key questions to address:

• • What shared state exists? Who reads/writes it?
• • What happens if two users book the same seat simultaneously?
• • Can you use optimistic locking (version numbers) vs pessimistic locking (mutex)?
• • Should you use database transactions (SELECT FOR UPDATE) instead of in-memory locks?

13.1 Reliability, Availability & Durability

Three terms often confused — each measures a different dimension of system trustworthiness:

The Nines of Availability

13.2 Fault Tolerance & Eliminating SPOFs

A Single Point of Failure (SPOF) is any component whose failure takes down the entire system. Fault tolerance means redundancy at every critical layer — no single server, rack, or data center is indispensable.

Failover Strategies

• • Active-Passive: standby replica takes over on primary failure (faster recovery, wasted idle capacity)
• • Active-Active: all nodes serve traffic simultaneously (higher utilization, conflict resolution needed)
• • Health-check driven: load balancer detects failure and reroutes within seconds

13.3 The CAP Theorem — The Fundamental Trade-off

Eric Brewer's CAP theorem states that a distributed data store can provide at most two of three guarantees simultaneously during a network partition:

13.4 PACELC — CAP Extended

Daniel Abadi's PACELC theorem extends CAP: If there is a Partition (P), choose Availability (A) or Consistency (C). Else (E), choose Latency (L) or Consistency (C). This captures the trade-off even when the network is healthy — strong consistency often requires coordination that adds latency.

13.5 Consistency Models

Consistency exists on a spectrum — not just "strong" or "eventual." Choose based on what your users can tolerate.

13.6 Replication Strategies

// Quorum consistency (leaderless — Cassandra/DynamoDB)
// N = number of replicas, W = write quorum, R = read quorum
// Strong consistency when W + R > N

N = 3 replicas
W = 2  (write must succeed on 2 of 3 nodes)
R = 2  (read from 2 of 3 nodes)
W + R = 4 > N = 3  →  guaranteed to overlap → consistent read

13.7 Designing for Failure — Interview Framework

In system design interviews, always address failure explicitly. Walk through this checklist:

1. Identify SPOFs: What single component failure kills the system?
2. Add redundancy: N+1 at every layer (servers, DB replicas, AZs)
3. Choose CAP position: CP for banking, AP for social feeds — justify it
4. Define failover: automatic vs manual, RTO (recovery time) and RPO (data loss window)
5. Plan degradation: what features can be disabled under stress? (circuit breakers, graceful degradation)
6. Backup & restore: how do you recover from catastrophic failure?

14.1 The CIA Triad & Defense in Depth

All security goals reduce to three pillars. Every control you design maps to at least one:

Defense in depth layers multiple security controls so no single failure compromises the system — like a castle with moat, walls, guards, and a vault.

14.2 Authentication vs Authorization

These are distinct concerns — conflating them is a common design mistake.

// JWT structure (Header.Payload.Signature)
// Payload contains claims — never store secrets in JWT!
{
  "sub": "user-123",
  "role": "admin",
  "exp": 1620000000,
  "iat": 1619996400
}

// API request
GET /api/v1/users
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

// Server validates: signature valid? not expired? role permits action?

14.3 Encryption — In Transit & At Rest

Encryption in transit: TLS 1.3 for all client-server and service-to-service communication. HTTPS is non-negotiable. Internal microservices should use mTLS (mutual TLS) so services authenticate each other.

Encryption at rest: Database-level encryption (AES-256), disk encryption, and field-level encryption for PII (SSN, credit cards). Use a Key Management Service (AWS KMS, HashiCorp Vault) — never hardcode keys.

14.4 Common Attack Vectors & Defenses

// WRONG — SQL injection vulnerable
query = "SELECT * FROM users WHERE email = '" + userInput + "'"

// RIGHT — parameterized query
query = "SELECT * FROM users WHERE email = ?"
db.execute(query, [userInput])

// Rate limiting at API gateway
// 100 req/min per IP → 429 Too Many Requests
// Prevents brute force and DDoS amplification

14.5 Secrets Management & Least Privilege

Never commit secrets to git. Use dedicated secret stores with automatic rotation:

• • HashiCorp Vault — dynamic secrets, encryption as a service
• • AWS Secrets Manager / GCP Secret Manager — cloud-native rotation
• • Environment injection — secrets injected at runtime, not baked into images

Principle of least privilege: every service account, API key, and IAM role gets only the minimum permissions required. A compromised read-only analytics service shouldn't be able to delete production databases.

14.6 Zero Trust & Security in Interviews

Zero Trust assumes no user or service is trusted by default — even inside the corporate network. Every request is authenticated, authorized, and encrypted. Micro-segmentation limits blast radius if one service is compromised.

Security Checklist for System Design Interviews

1. Authentication: How do users/services prove identity? (OAuth, JWT, API keys)
2. Authorization: Who can access what? (RBAC, resource-level checks)
3. Encryption: TLS in transit, encryption at rest for PII
4. Input validation: Sanitize all external input at API boundary
5. Rate limiting: Prevent abuse and brute force
6. Audit logging: Who did what, when — immutable logs for forensics
7. Compliance: GDPR, HIPAA, PCI-DSS if applicable

15.1 Monitoring vs Observability

Monitoring tells you when something is wrong — predefined dashboards and alerts fire when thresholds breach. Observability lets you ask why — exploring arbitrary questions about system behavior you didn't anticipate when writing alerts.

15.2 The Three Pillars of Observability

The pillars are complementary — metrics tell you something is wrong, logs tell you what happened, traces tell you where in the call chain it happened. Correlating all three (via trace IDs in logs) is the gold standard.

15.3 Golden Signals & RED/USE Methods

Google's SRE team defines four Golden Signals every user-facing service should monitor:

RED Method (for services)

Rate (requests/sec) · Error rate · Duration (latency distribution)

USE Method (for resources)

Utilization · Saturation · Errors — applied per resource: CPU, memory, disk, network.

// Example Prometheus metrics (RED)
http_requests_total{method="GET", status="200", endpoint="/api/urls"} 45230
http_requests_total{method="GET", status="500", endpoint="/api/urls"} 12
http_request_duration_seconds{quantile="0.99", endpoint="/api/urls"} 0.087

// Alert rule
ALERT HighErrorRate
  IF rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01
  FOR 5m
  LABELS { severity="critical" }

15.4 SLIs, SLOs, SLAs & Error Budgets

Reliability targets must be measurable and agreed upon. This hierarchy connects engineering to business:

15.5 Distributed Tracing

In microservices, a single user request traverses dozens of services. Distributed tracing assigns a unique trace_id at the edge and propagates it through every service call, creating a waterfall of spans.

OpenTelemetry is the vendor-neutral standard for generating traces, metrics, and logs. Instrument once, export to Jaeger, Datadog, or Honeycomb.

15.6 Alerting & On-Call Best Practices

• • Alert on symptoms, not causes: "Users experiencing high error rate" not "CPU is 82%"
• • Every alert must be actionable: if no one can do anything, it's a dashboard metric, not an alert
• • Reduce noise: group related alerts, use alert routing (PagerDuty, Opsgenie)
• • Severity levels: P1 (wake someone up) vs P3 (fix next business day)
• • Runbooks: every P1/P2 alert links to step-by-step remediation docs

// Structured logging — JSON for machine parsing
{
  "timestamp": "2024-06-15T10:23:45.123Z",
  "level": "ERROR",
  "service": "url-shortener-api",
  "trace_id": "abc123def456",
  "message": "Database connection timeout",
  "user_id": "user-789",
  "duration_ms": 5023,
  "endpoint": "POST /api/v1/urls"
}
// trace_id links this log entry to the distributed trace in Jaeger

15.7 Observability in System Design Interviews

Mentioning observability proactively signals production experience. Cover these in every design:

1. What to measure: Golden signals / RED metrics for each service
2. SLOs: "99.9% redirect success, p99 < 100ms"
3. Health checks: /health endpoint for load balancer
4. Tracing: propagate trace ID across services for debugging
5. Alerting: alert on error rate and latency SLO breaches
6. Dashboards: per-service Grafana boards for on-call engineers

16.1 Step 1 — Clarify Requirements

16.2 Step 2 — Back-of-the-Envelope Estimation

Writes/sec  = 100M / (30 × 24 × 3600)  ≈ 40/sec
Reads/sec   = 40 × 100                  ≈ 4,000/sec
Storage     = 100M × 12 × 5 × 500 bytes ≈ 3 TB (raw)
QPS peak    = 4,000 × 3 (burst factor) ≈ 12,000 reads/sec peak

→ Reads dominate → Redis cache + CDN essential
→ Writes modest → single DB shard OK initially
→ 3 TB → plan sharding at ~10 TB

16.3 Step 3 — API Design

POST   /api/v1/urls          → { long_url, custom_alias?, ttl? }  → 201 { short_url }
GET    /api/v1/urls/{code}   → metadata + click stats              → 200
DELETE /api/v1/urls/{code}   → deactivate                          → 204
GET    /{code}               → 301 redirect (separate from /api/)

16.4 Step 4 — High-Level Architecture

16.5 Step 5 — Deep Dive: Short Code Generation

Two approaches — discuss both in interviews:

// Base62 encode
function encode(num):
  chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
  result = ""
  while num > 0:
    result = chars[num % 62] + result
    num = num // 62
  return result.padStart(7, 'a')

16.6 Step 6–7 — Trade-offs & LLD Touchpoints

• • 301 vs 302 redirect: 301 permanent (browser caches — good for CDN), 302 allows changing destination
• • Cache-aside for reads; write-invalidate on URL update
• • Async analytics via Kafka — don't block redirect for click logging
• • LLD classes: UrlService, UrlRepository, Base62Encoder, CacheClient

17.1 Requirements & Scale

• • FRs: 1:1 chat, group chat (max 500), media sharing, read receipts, online presence
• • NFRs: 500M DAU, message delivery < 500ms, 99.9% availability, offline message sync
• • Scale: 500M DAU × 40 msgs/day = 20B msgs/day ≈ 230K msgs/sec

17.2 Architecture — WebSockets & Chat Servers

Key design: Clients maintain persistent WebSocket connections to chat servers. Redis stores user_id → server_id mapping so messages route to the correct server. Cassandra stores message history (write-heavy, time-series friendly).

17.3 Message Flow & Offline Delivery

1. User A sends message → Chat Server 1 → persist to Cassandra → publish to Kafka
2. Lookup User B in Redis → connected to Chat Server 2 → push via WebSocket
3. If User B offline → store in inbox table → push notification via APNs/FCM on reconnect
4. Group chat: fan-out message to all member connections (or fan-out on read for large groups)

17.4 Trade-offs

• • WebSocket vs long polling: WebSocket for real-time; fallback to long polling for restrictive networks
• • Small groups: fan-out on write. Large groups (1000+): fan-out on read
• • Message ordering: per-conversation sequence numbers; causal ordering for group chats
• • Sticky sessions required for WebSocket — or use Redis pub/sub between chat servers

18.1 Requirements & Scale

• • FRs: Post tweets/photos, follow users, view personalized home feed, like/comment
• • NFRs: 300M DAU, feed load < 500ms, 500 follows max per user (simplified)
• • Scale: 300M DAU, 200M posts/day, avg user follows 200 people, read:write ≈ 100:1

18.2 Fan-out on Write vs Fan-out on Read

18.3 Feed Architecture

Post service writes to posts table. Fan-out worker pushes post IDs into each follower's Redis feed cache (sorted set by timestamp). Feed service reads top N post IDs from cache, hydrates full post content from posts store.

// Redis feed cache per user (sorted set — score = timestamp)
ZADD feed:user-123  1620000000  "post-456"
ZADD feed:user-123  1620003600  "post-789"

// Get home feed — top 20 most recent
ZREVRANGE feed:user-123 0 19

// Celebrity threshold: if follower_count > 1M → skip fan-out, pull on read

18.4 Key Trade-offs

• • Storage: pre-computed feeds use more storage (post ID × followers) but enable fast reads
• • Ranking: production feeds use ML ranking — start with chronological, mention ranking as extension
• • Media: store images/videos in CDN (S3 + CloudFront), feed cache stores only metadata + URLs

19.1 The 45-Minute Timeline

19.2 Communication Tactics That Win

• • Think aloud: narrate your reasoning — silence makes interviewers nervous
• • State assumptions: "I'll assume 100M DAU unless you say otherwise"
• • Propose, don't dictate: "I'd lean toward Redis here — does that align with your constraints?"
• • Name trade-offs: every decision gets a "because X, trade-off is Y, mitigated by Z"
• • Check in: "Should I go deeper on the database layer or move to caching?"
• • Draw while talking: diagrams on whiteboard/Excalidraw beat pure verbal descriptions

19.3 Common Mistakes to Avoid

19.4 What Interviewers Evaluate

20.1 The Complete Mental Map

20.2 Self-Assessment Checklist

Can you confidently explain each of these without notes?

20.3 Continued Learning Roadmap

• • Practice: Design 2 systems/week on Excalidraw — Uber, Netflix, Dropbox, Rate Limiter
• • Read: "Designing Data-Intensive Applications" by Martin Kleppmann (the bible)
• • Watch: System Design Interview channels — mock interviews with narration
• • Build: Implement a URL shortener or chat app — theory becomes intuition through code
• • Mock interviews: Pramp, interviewing.io, or peer practice with this course's frameworks