logo
CHEATSHEETSTOOLSABOUT中文

System Design Interview Questions

System design interviews evaluate your ability to architect scalable, reliable, and maintainable software systems from scratch. Unlike coding interviews that test algorithms and data structures on a single machine, system design tests your engineering judgment, trade-off analysis, and breadth across distributed systems.

The 4-Step Interview Framework

The most common failure mode in system design interviews is diving immediately into drawing architectural boxes before clarifying requirements. Structure your conversation using this 4-step framework:

[ Step 1: Scope & Clarify ]  ───►  [ Step 2: High-Level Design ]
          │                                      │
          ▼                                      ▼
[ Step 3: Deep Dive Components ] ───►  [ Step 4: Scale & Bottlenecks ]

Step 1: Clarify Requirements & Scope (3–5 mins)

Never assume requirements. Ask clarifying questions to establish boundaries:

  • Functional Requirements: What are the 2 or 3 core capabilities? (e.g., "A user can submit a long URL and get a short alias; visiting the short alias redirects to the original URL").
  • Non-Functional Requirements: What are the quality attributes?
    • Availability vs. Consistency (see CAP Theorem)
    • Latency targets (e.g., read latency < 10ms, write latency < 100ms)
    • Durability and retention (e.g., expire after 2 years or store forever)
  • Scale & Capacity Estimations:
    • Read vs. write ratios (e.g., 100:1 read-heavy)
    • Incoming QPS, daily data ingress, and cache memory working sets (see Estimations)

Step 2: High-Level Architecture & Core APIs (10–15 mins)

Establish the skeleton of the system:

  • API Contracts: Define primary endpoints, request payloads, and status codes (see API Design).
  • Data Models: Propose initial entities, primary keys, and relationships.
  • End-to-End Diagram: Draw the end-to-end request flow: Client -> Load Balancer / API Gateway -> Stateless App Servers -> Storage & Cache.

Step 3: Deep Dive into Core Components (15–20 mins)

Drill down into the hardest technical problem specific to this question:

  • How are unique identifiers generated without collision? (see ID Generation)
  • How does the system handle high concurrency and avoid blocking I/O? (see C10K and C10M and Network Programming Models)
  • What caching patterns fit the read pattern? (see Caching)
  • How does asynchronous processing prevent bottlenecking client requests? (see Messaging)

Step 4: Scale, Bottlenecks, and Failure Modes (5–10 mins)

Showcase senior engineering maturity by evaluating limits:

  • Single Points of Failure (SPOFs): What happens if a master database node or cache crashes?
  • Data Partitioning & Sharding: How do we partition data when tables exceed single-node limits?
  • Traffic Spikes & Cascading Failures: How does the system protect downstream backends using Throttling and Backpressure?
  • Fault Recovery: Circuit breakers, retries with exponential backoff and jitter, and health checks (see Reliability).

Architectural Building Blocks Reference

Every system design problem is assembled from a core set of distributed building blocks. Master each concept and its trade-offs:

Building Block Primary Purpose Architectural Trade-offs Relevant Guide
API Gateway & Proxies Routing, TLS termination, load balancing Adds network hop; must be scaled horizontally Proxy
Caching Low-latency reads, reducing DB load Cache invalidation complexity, stale data risks Caching
ID Generation Generating unique, sortable primary keys Centralized counter vs. decentralized bit layouts ID Generation
Message Brokers Decoupling producers & consumers, smoothing spikes Eventual consistency, message ordering, at-least-once deduplication Messaging
Service Discovery & Mesh Dynamic routing across ephemeral instances Operational complexity, sidecar proxy overhead Service Discovery / Sidecar
Consensus & State Leader election, distributed lock coordination Sacrifices availability under network partitions Consensus / CAP Theorem
Rate Limiting Preventing abuse, protecting downstream resources Latency overhead on critical path, fail-open vs fail-closed Throttling / Rate Limiter
Backpressure Flow control across unbalanced pipeline stages Dropping excess load vs. buffering in queues Backpressure

High-Frequency Interview Question Archetypes

Most system design questions fall into recognizable archetypes. Click on any dedicated case study for full deep-dives:

1. Read-Heavy URL & Key-Value Services

  • Classic Questions: Design TinyURL, Bit.ly, or an ephemeral Pastebin.
  • Core Concepts: Base62 encoding, 64-bit distributed counters, cache-aside strategy with LRU eviction, and HTTP 301 Moved Permanently vs. 302 Found redirection trade-offs.
  • Deep Dive: System Design - URL Shortener (TinyURL)

2. Traffic Protection & Quota Management

  • Classic Questions: Design an API Rate Limiter, Stripe payment throttle, or DDoS shield.
  • Core Concepts: Token bucket, sliding window counters, atomic Redis Lua scripts, distributed race conditions, and fail-open resilience strategies.
  • Deep Dive: System Design - Distributed Rate Limiter

3. Fan-Out & Social Feed Timelines

  • Classic Questions: Design Twitter / X Timeline, Facebook News Feed, or Instagram Feed.
  • Core Concepts: Fan-out on write (push) vs. fan-out on read (pull), handling viral "celebrity" accounts, Redis sorted set timeline storage, and cursor-based pagination.
  • Deep Dive: System Design - News Feed & Timeline

4. Low-Latency Prefix Search

  • Classic Questions: Design Google Search Autocomplete, Amazon Typeahead, or Typeahead for friend search.
  • Core Concepts: In-memory Trie data structures, precomputing top-k completions at each node, asynchronous offline data aggregation pipelines (Kafka → Flink → Trie Builder), and client-side debouncing.
  • Deep Dive: System Design - Search Typeahead

5. Streaming Analytics & Top-K Heavy Hitters

  • Classic Questions: Design a YouTube trending video counter, top-searched keywords in the last 1 hour, or real-time view counts.
  • Key Techniques:
    • Count-Min Sketch (probabilistic data structure for frequency estimation in streaming data).
    • Sliding window aggregation across time buckets (e.g., 1-minute buckets aggregated into 1-hour rolls).
    • Multi-stage MapReduce / stream processing to find global heavy hitters without centralizing raw traffic.

6. Real-Time Chat & Notification Services

  • Classic Questions: Design WhatsApp, Slack, Facebook Messenger, or a Push Notification service.
  • Key Techniques:
    • Bidirectional communication: WebSockets for active messaging; fallback to HTTP long polling or Server-Sent Events (SSE).
    • Ephemeral connection managers maintain open socket state per host; message routing coordinated via a distributed pub/sub broker (like Redis or Kafka).
    • User Presence: Periodic heartbeats stored with expiring keys in a fast in-memory key-value store.

7. Large-Scale File & Media Storage

  • Classic Questions: Design YouTube video ingestion, Google Drive, or Dropbox.
  • Key Techniques:
    • Separation of Metadata Plane (SQL/NoSQL database for file trees, user permissions, versioning) and Data Plane (Object storage like Amazon S3 or Google Cloud Storage).
    • Client-side chunking: Split large files into 4MB–8MB chunks, hash each chunk, and upload chunks concurrently to support resumable uploads and deduplication.
    • Asynchronous background transcoding pipelines driven by message queues.

Mental Math & Estimation Cheat Sheet

Use these quick rules of thumb during back-of-the-envelope calculations:

Time & Scale Equivalents

  • 1 day ≈ 86,400 seconds ≈ 10^5 seconds.
  • 1 million requests / day ≈ 12 requests / second.
  • 100 million requests / day ≈ 1,200 requests / second.
  • 1 billion requests / day ≈ 12,000 requests / second.
  • Peak traffic: Typically plan for 2× to 5× average QPS.

The 80/20 Rule for Caching

In read-heavy applications, 20% of content generates 80% of read traffic. To cache the hot working set for a day: Cache RAM Needed = Daily Read Requests × 0.20 × Average Object Size

Latency Numbers Every Engineer Should Know

  • L1 CPU cache reference: ~ 0.5 ns
  • Main Memory (RAM) read: ~ 100 ns
  • Read 1MB sequentially from SSD: ~ 16,000 ns (16 μs)
  • Intra-datacenter round-trip network ping: ~ 0.5 ms (500 μs)
  • Cross-continent round-trip ping (US to Europe): ~ 100 ms

5 Common Traps to Avoid

  1. Jumping Straight to Technology Names: Avoid stating "We will use Kafka, MongoDB, and Redis" before explaining why. Focus on architectural patterns (event streams, document storage, in-memory caches) and explain the access pattern that justifies the specific engine.
  2. Ignoring Concrete Numbers: Failing to estimate data volume leads to inappropriate choices (e.g., proposing a complex sharded NoSQL database for data that easily fits on a single PostgreSQL instance with read replicas).
  3. Designing for Happy Paths Only: Real distributed systems experience network partitions, disk errors, and node crashes. Always highlight how your design handles failures, timeouts, and data loss.
  4. Neglecting Edge Cases & Hotspots: Identify write bottlenecks (such as a celebrity with 80M followers in a news feed, or a viral link in a URL shortener) and demonstrate how your architecture prevents these hotspots from taking down the cluster.
  5. Over-Engineering from Second One: Start with the simplest viable architecture that meets baseline functional needs. Scale up incrementally, explaining the bottlenecks that each new layer (caching, sharding, message queues) resolves.
Loading...