Every system design interview question you have ever studied — URL shorteners, web crawlers, notification systems, news feeds, chat systems, search autocomplete, video platforms, file storage — teaches you a specific pattern. But in a real interview, nobody asks you to implement a single pattern in isolation. They ask you to build a complete system from scratch, on a blank whiteboard, in 45 minutes, while explaining your reasoning out loud. The skill that matters is not knowing any single pattern; it is knowing how to combine them into a coherent architecture under time pressure.

This is the meta-skill of system design: the ability to take an ambiguous problem statement ("Design Uber Eats" or "Design a real-time analytics dashboard"), decompose it into structured phases, make deliberate trade-offs at each phase, and produce an architecture that is both correct and defensible. It is the difference between an engineer who can describe how consistent hashing works and an engineer who knows when to reach for consistent hashing versus range-based sharding based on the access patterns they derived from the requirements.

The five-phase framework you will learn here is not an academic exercise. It is the same methodology used in production design reviews at companies like Google (where it is called a Design Doc review), Amazon (where it maps to the Working Backwards PR/FAQ process), and Netflix (where architecture reviews follow a structured template). The interview format is a compressed version of this production process, testing whether you can think through a system from end to end without getting lost.

The critical insight that most candidates miss is that the five phases are not just a checklist — they are a dependency chain. Requirements drive estimation. Estimation constrains architecture. Architecture reveals which components need depth. Depth exposes cross-cutting concerns. Skip any phase and the entire downstream chain becomes unreliable. An architecture drawn without estimation might be 10x over-provisioned or 10x under-provisioned, and you would never know.

Throughout this lesson, you will see how each phase builds on the previous one, and you will practice the complete methodology twice with two different systems. By the end, you will have internalized a repeatable framework that works for any system design problem you encounter.

Requirements gathering is the single most important phase of any system design exercise. It is also the phase most frequently skipped by candidates who are eager to show technical depth. The irony is that skipping requirements is itself a signal of shallow thinking — senior engineers know that the requirements determine the architecture, not the other way around.

In an interview setting, the problem statement is deliberately vague. "Design Twitter" could mean design the tweet creation and timeline system, or the trending topics algorithm, or the notification pipeline, or the search infrastructure. Each of these is a completely different architecture. The interviewer is testing whether you ask the right questions to narrow scope, or whether you assume scope and risk solving the wrong problem.

Scope negotiation is a subtle but powerful skill. When the interviewer says "Design Uber," they do not expect you to design the entire Uber ecosystem in 45 minutes. They expect you to identify the core components, propose a focused scope, and go deep on that scope. The best candidates proactively say: "I will focus on the ride-matching and real-time tracking system, and defer the payment processing and surge pricing algorithm as out-of-scope for today. Does that work?"

The output of Phase 1 should be a crisp written or verbal summary: "We are building a food delivery platform for 50M DAU. Core use cases: restaurant browsing, order placement, real-time delivery tracking. Non-functional: 99.9% availability, < 500ms order confirmation, eventual consistency acceptable for tracking updates. Out of scope: payment processing, restaurant onboarding, menu management." This summary becomes the contract for the rest of the interview.

Capacity estimation translates the qualitative requirements from Phase 1 into quantitative constraints that drive every architectural decision. It is the bridge between "we need to handle a lot of traffic" and "we need 17 application servers behind a load balancer, a Redis cluster with 64 GB of memory, and a sharded database with 5 partitions." Without estimation, architecture is guesswork.

The estimation chain always follows the same sequence: start with users, derive requests, derive storage, derive bandwidth, derive memory. Each step feeds the next. Here is the universal template that works for any system:

graph LR
    A[DAU: 50M] --> B[Daily Actions: 525M]
    B --> C[Avg QPS: 6,100]
    C --> D[Peak QPS: 30,000]
    D --> E{Architecture Decision}
    E -->|QPS < 1K| F[Single Server]
    E -->|QPS 1K-10K| G[Load Balancer + 3-5 Servers]
    E -->|QPS 10K-100K| H[Sharded DB + Cache + LB]
    E -->|QPS > 100K| I[Multi-Region + CDN + Sharding]
    B --> J[Storage: 25 GB/day]
    J --> K[5-Year: 45 TB]
    K --> L{Storage Decision}
    L -->|< 1TB| M[Single DB Instance]
    L -->|1-10TB| N[Read Replicas + Partitioning]
    L -->|> 10TB| O[Sharded Database]

A common mistake is treating estimation as a one-time exercise at the start of the interview. In practice, you should re-estimate whenever you make a significant design choice. When you decide to add a cache, estimate the cache hit rate and recalculate the database QPS. When you decide to shard, estimate the per-shard QPS and verify each shard can handle it. Estimation is a continuous process, not a phase.

With requirements defined and capacity estimated, you now draw the high-level architecture. This is what most people think of when they hear "system design" — the boxes and arrows. But the boxes and arrows are not random. Every system you will ever design at internet scale uses the same canonical set of components, arranged in a predictable pattern. The skill is knowing which components your specific system needs (based on your estimates) and how data flows through them.

graph TB
    subgraph Clients
        Web[Web Browser]
        Mobile[Mobile App]
        API[API Consumer]
    end
    subgraph Edge
        CDN[CDN / CloudFront]
        LB[Load Balancer / API Gateway]
    end
    subgraph Services
        S1[Service A]
        S2[Service B]
        S3[Service C]
    end
    subgraph Data
        Cache[(Redis Cache)]
        DB[(Primary DB)]
        ReadDB[(Read Replicas)]
        Queue[Message Queue / Kafka]
        S3Store[Object Storage / S3]
    end
    subgraph Async
        Worker[Async Workers]
        Search[(Search Index)]
        Analytics[(Analytics Store)]
    end
    Web --> CDN
    Mobile --> LB
    API --> LB
    CDN --> LB
    LB --> S1
    LB --> S2
    LB --> S3
    S1 --> Cache
    S2 --> Cache
    Cache -->|miss| DB
    S1 --> DB
    DB --> ReadDB
    S2 --> ReadDB
    S1 --> Queue
    S3 --> S3Store
    Queue --> Worker
    Worker --> Search
    Worker --> Analytics

The architecture should tell a story. Walk the interviewer through the primary use case: "A user opens the app, the request hits our CDN for static assets, then the API gateway for the restaurant listing API. The gateway routes to the restaurant service, which checks Redis for the cached listing. On cache miss, it queries the read replica. The response is cached for 5 minutes and returned. The whole flow takes approximately 50 milliseconds at p95."

A powerful technique is to draw the architecture incrementally. Start with the simplest possible version that works (client, single server, single database), then add components as your estimates demand. This shows the interviewer that you understand scaling as an incremental process, not a one-shot design. It also naturally creates discussion points: "At our estimated 30K peak QPS, a single database cannot handle the reads, so I am adding a Redis cache here to reduce database load by approximately 90%."

The high-level architecture demonstrates breadth. The deep dive demonstrates depth. In the FAANG leveling rubric, breadth without depth is an L4 signal (knows the components but cannot reason about trade-offs). Depth on one or two components is the L5-L6 differentiator. Depth on cross-cutting concerns across components is the L6-L7 signal.

Choosing what to deep-dive is itself a skill. You want to pick a component that (1) is critical to the system functioning correctly, (2) has interesting trade-offs worth discussing, and (3) plays to your strengths. The interviewer may also direct you: "Tell me more about how the database handles this at scale." Follow their lead if they redirect.

Trade-off articulation is the most important skill at the L6 level. Every design decision is a trade-off, and the interviewer wants to hear that you understand what you are giving up. "I chose eventual consistency for the restaurant listings cache because a user seeing a slightly stale menu is acceptable, but I chose strong consistency for the order placement flow because charging a user for an unavailable item is not acceptable." This sentence demonstrates more maturity than an hour of component descriptions.

Remember that the deep dive should always connect back to the requirements you established in Phase 1. If the requirement says "< 200ms p99 for order confirmation," your deep dive should explain exactly how the order processing pipeline achieves that latency target: "The synchronous path is client to API gateway (5ms) to order service (10ms) to database write (20ms) to payment confirmation (100ms) to response (5ms) = 140ms total. Async work (notifications, analytics) is offloaded to the message queue and does not affect user-facing latency."

Cross-cutting concerns are the architectural qualities that span all components rather than living in any single one. Caching, monitoring, security, rate limiting, and disaster recovery do not belong to any specific microservice — they are systemic properties. Addressing them is what separates a senior answer (L5+) from a junior one (L4). Junior engineers design systems that work. Senior engineers design systems that work, and that you can operate, observe, secure, and recover when things go wrong.

The strongest signal of production experience is when cross-cutting concerns influence your component choices rather than being bolted on after the fact. For example: "I chose Kafka over RabbitMQ for the event bus because Kafka provides message replay, which is critical for our disaster recovery strategy — if a consumer fails, we can replay events from the last checkpoint rather than losing them." This shows that DR thinking informed the technology choice, not the other way around.

Let us now apply the entire five-phase framework to a complete system design problem. This walkthrough simulates a 45-minute FAANG interview for the prompt: "Design an e-commerce platform like Amazon." We will follow the REACH framework (Requirements, Estimation, Architecture, Component deep-dive, Hardening) and show how each phase builds on the previous one.

graph TB
    subgraph Clients
        Web[Web App]
        Mobile[Mobile App]
    end
    subgraph Edge
        CDN[CDN - images and static]
        GW[API Gateway + Auth + Rate Limit]
    end
    subgraph Services
        PS[Product Service]
        CS[Cart Service]
        OS[Order Service]
        PAY[Payment Service]
        INV[Inventory Service]
        TRACK[Order Tracking Service]
        SRCH[Search Service]
    end
    subgraph Data
        PDB[(Product DB - Postgres)]
        CDB[(Cart DB - Redis)]
        ODB[(Order DB - Postgres Sharded)]
        INVDB[(Inventory DB - Postgres)]
        ES[(Elasticsearch)]
        S3[S3 - Images]
        Kafka[Kafka Event Bus]
    end
    Web --> CDN
    Mobile --> GW
    CDN --> GW
    GW --> PS
    GW --> CS
    GW --> OS
    GW --> SRCH
    PS --> PDB
    CS --> CDB
    OS --> ODB
    OS --> PAY
    OS --> INV
    INV --> INVDB
    SRCH --> ES
    PS --> S3
    OS --> Kafka
    Kafka --> TRACK
    Kafka --> ES

For the inventory management deep-dive, the key challenge is the flash sale scenario. When 10,000 users try to buy the last 100 units of a product simultaneously, naive approaches fail: SELECT available FROM inventory WHERE product_id = X followed by UPDATE inventory SET available = available - 1 has a classic race condition. The solution is optimistic locking: UPDATE inventory SET available = available - 1, version = version + 1 WHERE product_id = X AND version = current_version AND available > 0. If the update affects zero rows, the item is either out of stock or another transaction won the race. The client retries or shows "out of stock."

This walkthrough demonstrates the complete REACH framework in action. Notice how each phase constrained the next: the 115K peak browse QPS drove the need for a 200GB Redis cache and Elasticsearch (Postgres alone cannot serve 115K QPS). The 5M orders/day drove the sharded Orders DB and the saga-based order processing pipeline. The flash sale requirement drove the optimistic locking strategy for inventory.

For our second complete walkthrough, we tackle a fundamentally different system: "Design a real-time analytics dashboard that shows website traffic metrics (page views, unique visitors, top pages, geographic distribution) with updates every 5 seconds for customers with up to 1 billion events per day." This exercises different patterns: streaming data ingestion, time-series storage, pre-aggregation, and real-time visualization.

graph LR
    subgraph Ingestion
        SDK[JS Tracking SDK]
        EDGE[Edge Collectors - Global PoPs]
        KAFKA[Kafka - Event Stream]
    end
    subgraph Processing
        FLINK[Stream Processor - Flink]
        AGG[Pre-Aggregation Service]
    end
    subgraph Storage
        RAW[(Raw Events - S3 / Parquet)]
        TSDB[(Time-Series DB - ClickHouse)]
        CACHE[(Redis - Live Counters)]
    end
    subgraph Serving
        API[Query API Service]
        WS[WebSocket Server]
        DASH[Dashboard UI]
    end
    SDK -->|HTTP POST| EDGE
    EDGE -->|Batch + Forward| KAFKA
    KAFKA --> FLINK
    FLINK -->|5-sec windows| AGG
    AGG --> TSDB
    AGG --> CACHE
    FLINK -->|Raw archival| RAW
    TSDB --> API
    CACHE --> WS
    API --> DASH
    WS -->|Push updates| DASH

The architecture for this system is fundamentally different from the e-commerce platform. Instead of request-response, we have a streaming pipeline. The key insight is the separation between the ingestion path (which must handle 58K events/sec at peak without dropping any) and the query path (which serves 2K dashboard queries/sec). These two paths have completely different performance profiles and can be scaled independently.

For the deep dive on ClickHouse as the time-series database choice: ClickHouse uses columnar storage, which compresses time-series data extremely well (10-20x compression ratios are common). A query like "show page views per hour for the last 7 days for customer X" only reads the page_views column and the timestamp column, skipping all other columns. With the MergeTree engine and proper partitioning by date and customer_id, this query scans roughly 2MB of compressed data and returns in under 100 milliseconds.

Notice how this system uses different patterns than the e-commerce platform: streaming ingestion instead of request-response, pre-aggregation instead of query-time computation, HyperLogLog instead of exact counting, WebSocket push instead of polling. The requirements drove these choices: 5-second freshness with 1 billion events per day makes query-time aggregation over raw data impossible (scanning 500GB of daily data every 5 seconds would require unrealistic disk throughput). Pre-aggregation is the only viable strategy, and this insight comes directly from the capacity estimation.

After studying hundreds of system design interview debriefs from FAANG candidates, a clear set of anti-patterns emerges. These mistakes are not about lacking technical knowledge — they are about process failures that prevent candidates from demonstrating the knowledge they have. Avoiding these mistakes is often the difference between a borderline and a strong hire signal.

The final skill is self-evaluation. After practicing a system design problem, grade yourself on each phase using the rubric above. Record yourself (audio or video) doing a 45-minute mock interview and watch it back. You will immediately notice where you spend too long, where you forget phases, and where your explanations lack clarity. The candidates who pass system design interviews are not the ones with the most knowledge — they are the ones who have practiced presenting their knowledge in a structured, time-boxed format.