Interview Prep Hub

System Design

System design rounds evaluate your ability to architect scalable, resilient systems. Interviewers expect you to drive the conversation, ask clarifying questions, and discuss trade-offs explicitly.

The Framework (Memorize This)

  1. Clarify Requirements (5 min): Functional (What does the system do?) and Non-Functional (Scale, latency, consistency, availability). Ask about read-to-write ratios.
  2. Capacity Estimation (3-5 min): Daily Active Users (DAU), QPS (Queries Per Second), bandwidth, storage per year. Keep math simple (use powers of 10).
  3. API Design (5 min): Define endpoints, methods, and JSON payloads.
  4. Data Model (5 min): Relational vs NoSQL, tables/collections, partition keys.
  5. High-Level Architecture (10 min): Draw the boxes: Client → LB → Gateway → App Servers → Cache → DB.
  6. Deep Dives (10-15 min): Discuss bottlenecks, sharding, caching strategies, async queues.
  7. Trade-offs (5 min): Why NoSQL over SQL here? Why pull over push model? Acknowledge what breaks first.

Capacity Estimation Cheat Sheet

Use these numbers to do quick back-of-the-envelope math.

QuantityMagnitude
1 Day86,400 seconds (Round to 100,000 for math)
2.5 Million Requests / Month~1 Request / Second
100 Million Requests / Day~1,000 Requests / Second (QPS)
1 KB per message * 1000 QPS1 MB / second = ~2.5 TB / month

Latency Numbers Every Programmer Should Know

Latency numbers — log scale, each gridline is 10x 1ns100ns10us1ms100ms10s L1 cache ref0.5 ns Branch mispredict5 ns Mutex lock/unlock25 ns Main memory ref100 ns SSD random read150 us Read 1MB from SSD1 ms Disk seek10 ms Same-datacenter RTT0.5 ms CA to Netherlands RTT150 ms
Orders of magnitude are what matter. A cross-continent round trip costs as much as 1,500 SSD reads — which is why chatty APIs and N+1 queries hurt.
OperationTime
L1 cache reference0.5 ns
Read from main memory100 ns
Read 1 MB sequentially from SSD1 ms
Disk seek (HDD)10 ms
Round trip within same datacenter500 µs (0.5 ms)
Send packet CA to Netherlands150 ms

Core Concepts to Master

CAP Theorem & PACELC

P — Partition tolerance C — Consistency A — Availability P is not a choice on a real network so the real decision is CP or AP during a partition CP: refuse writes ledgers, inventory, auth AP: keep serving feeds, carts, analytics PACELC adds: Else, with no partition — trade Latency against Consistency
Partitions are not optional, so the real choice is C or A during one. PACELC adds: even when healthy, you trade latency against consistency.

CAP Theorem: In a distributed system, you can only guarantee two out of three: Consistency, Availability, Partition Tolerance. Since network partitions (P) are unavoidable, you must choose between Consistency (CP) and Availability (AP).

PACELC Theorem: Extends CAP. If Partition (P), choose Availability (A) or Consistency (C). Else (E) - when running normally - choose Latency (L) or Consistency (C).

Database Scaling

Rendering diagram…

Rendering diagram…

  • Vertical Scaling (Scale Up): Buy a bigger server. Easy, but has a hard limit and no redundancy.
  • Horizontal Scaling (Scale Out): Add more servers. Harder to implement (requires sharding), but infinite scale.
  • Read Replicas: Route all writes to the Master, route reads to Replicas. Great for read-heavy systems (e.g. 100:1 read-to-write ratio).
  • Sharding (Data Partitioning): Splitting a massive DB into smaller DBs.
    Challenge: Choosing the right Shard Key to avoid "hot spots" (e.g. don't shard by alphabet if 'S' is 30% of users).

Consistent Hashing

Node A Node B Node C k1 k2 k3 a key belongs to the next node clockwise hash(key) % N N goes 4 → 5 ~80% of keys map somewhere new the cache is effectively wiped consistent hashing ring Node C leaves → only ITS keys move to the next node clockwise everything else stays put virtual nodes spread each node over many ring points Used by Redis Cluster, Cassandra, DynamoDB, CDN and shard routing
Plain modulo remaps almost every key when the node count changes. A hash ring moves only the keys owned by the node that left.

When you have a cluster of cache servers (e.g., 4 Redis nodes), a standard hash hash(key) % N breaks completely if you add or remove a node (all data gets reshuffled). Consistent hashing maps both data and servers onto a circular ring. A key is assigned to the next server clockwise on the ring. Adding/removing a server only affects its immediate neighbors (1/N of the data moves).

Load Balancing

Rendering diagram…

  • L4 (Transport Layer): Routes based on IP and Port. Very fast, unaware of content.
  • L7 (Application Layer): Routes based on HTTP headers, URLs, cookies. Can do SSL termination and smart routing.
  • Algorithms: Round Robin, Least Connections, IP Hash.

Common Interview Designs

Design a URL Shortener (e.g., bit.ly)

Requirements: High availability, fast redirects. Short URLs shouldn't be guessable.

Core Logic: Generate a unique ID (from a Ticket Server or auto-increment DB), encode it using Base62 ([a-zA-Z0-9] = 62 chars). A 7-character base62 string supports 62^7 = 3.5 Trillion URLs.

Storage: Key-Value store (DynamoDB or Cassandra) is perfect since lookups are purely by ID.

Caching: Heavily cache redirects in Redis. Use LRU eviction. Caching is highly effective here (Pareto principle: 20% of URLs get 80% of traffic).

Design a Rate Limiter

Algorithms:

  • Token Bucket: Buckets hold tokens. Refill at fixed rate. Request costs 1 token. Best overall.
  • Leaking Bucket: Queue holds requests. Process at fixed rate. Smooths out traffic spikes.
  • Fixed Window: Counter per minute. Flaw: spikes at the edges of windows (e.g. 23:59:59 to 00:00:01).
  • Sliding Window Log: Keep exact timestamps in Redis Sorted Sets. Perfect accuracy, high memory cost.

Architecture: Place it at the API Gateway level. Store counts in Redis.

Design a Notification System

Components: API Gateway → Rules Engine (check preferences) → Message Queue (Kafka/SQS) → Dispatch Workers (Email, SMS, Push).

Critical elements: Idempotency (don't send twice), Dead Letter Queues (for failed sends), 3rd party rate limits, Retry logic with exponential backoff.

Design a News Feed (e.g., Twitter/Instagram)

Push Model (Fan-out on Write): When Alice tweets, workers instantly push the tweet to the feeds of all her followers in Redis. Reads are fast (O(1)), writes are slow for celebrities (Justin Bieber has 100M followers - doing 100M writes takes too long).

Pull Model (Fan-out on Read): Feed is generated on the fly when Bob opens the app by querying all people he follows. Writes are fast, reads are painfully slow.

Hybrid (The Solution): Use Push for normal users. Use Pull for celebrities. Bob's feed = pre-computed Push feed + live-queried Celebrity tweets.

Design a Key-Value Store (e.g., DynamoDB/Cassandra)

Data Partitioning: Consistent Hashing to distribute data across nodes.

Replication: Replicate data to N nodes across different datacenters for high availability.

Consistency: Quorum consensus. W + R > N to guarantee strong consistency. (Write to W nodes, Read from R nodes, out of N total replicas).

Conflict Resolution: Vector clocks or Last-Write-Wins (LWW) to resolve simultaneous updates.

Caching Strategies

Rendering diagram…

Rendering diagram…

  • Cache-Aside (Lazy Loading): App asks cache. If miss, app asks DB, writes to cache, returns to user. (Best for read-heavy).
  • Write-Through: App writes to cache, cache synchronously writes to DB. (Data is always consistent, but writes are slower).
  • Write-Behind (Write-Back): App writes to cache, cache immediately returns success, then asynchronously writes to DB. (Fastest writes, but data loss risk if cache crashes).
  • Eviction Policies: LRU (Least Recently Used) is standard. LFU (Least Frequently Used) is good for heavy tails. FIFO (First In First Out).

Load Balancing Algorithms

  • Round Robin: Distribute requests sequentially. Fails if servers have different capacities.
  • Weighted Round Robin: Assign weights (e.g., Server A gets 3x traffic of Server B based on RAM/CPU).
  • Least Connections: Send traffic to the server with the fewest active connections. Great for long-lived connections (WebSockets).
  • IP Hash: Hash the client's IP to assign them to a consistent server. Good for sticky sessions (though stateless servers + Redis is better).

Important Trade-offs to Discuss

  • SQL vs NoSQL: SQL for ACID transactions and relational data. NoSQL for massive horizontal scale, flexible schemas, and key-value lookups.
  • Long Polling vs WebSockets vs Server-Sent Events: Polling is bad. Long Polling is okay for rare updates. WebSockets for bi-directional high-frequency (chat, games). SSE for unidirectional server-to-client (stock tickers).
  • Microservices vs Monolith: Monoliths are faster to build and have no network latency. Microservices allow independent scaling, tech diversity, and isolated deployments, but introduce massive operational complexity (tracing, network failures).

Interview Quick Reference

ConceptWhen to use it
CDN (Cloudflare, CloudFront)Serving static assets globally with low latency.
API GatewayRate limiting, authentication, request routing, SSL termination.
Message Queue (Kafka/RabbitMQ)Async processing, decoupling microservices, buffering high traffic (bursts).
Redis / MemcachedCaching DB queries, session storage, distributed locks, leaderboards (Sorted Sets).
ElasticsearchFull-text search, log aggregation, complex faceted querying.
Consistent HashingDistributing data across a cluster of servers without mass re-shuffling on scale out/in.
Gossip ProtocolPeer-to-peer state sharing in decentralized clusters (Cassandra/Redis Cluster).