System Design Interview Guide 2026 — RADIO Framework, Canonical Problems, and Trade-offs

Introduction#

Why This Matters#

System design is the round that separates mid-level engineers from senior ones. Companies use it to evaluate how you reason about scale, availability, and trade-offs — not just whether you can write correct code. At FAANG and equivalent companies, a strong system design performance can be the deciding factor between an L4 and L5 offer.

Candidates who fail system design rounds typically share one of two failure modes: they jump into implementation details before establishing requirements, or they describe components without justifying why they chose them. This guide gives you a repeatable framework and seven canonical problems to eliminate both issues.

The RADIO Framework#

Structure every 45-minute system design interview with RADIO:

R — Requirements
  Functional:     What must the system do? (core features only)
  Non-functional: Scale, availability, latency, consistency targets
 
A — API Design
  Define endpoints / contracts before touching internals
  REST, GraphQL, or gRPC — state your choice and rationale
 
D — Data Model
  What entities exist? Relationships? Size estimates?
  SQL vs NoSQL decision with justification
 
I — High-Level Design
  Draw the box diagram: clients, load balancers, servers, DBs, caches, queues
  Walk through core user flows
 
O — Deep Dives
  Pick 2-3 components the interviewer signals interest in
  Show depth: replication, sharding, failure modes, monitoring

Spend roughly 5 minutes on R, 5 on A, 5 on D, 15 on I, and 15 on O. Interviewers guide the O section — watch for verbal and non-verbal cues.

Canonical Problem 1 — URL Shortener#

Scale targets: 100M URLs created per month, 10:1 read/write ratio.

Capacity estimation:

• Writes: 100M / 30 / 86,400 ≈ 40 writes/sec
• Reads: 400 reads/sec
• Storage: 100M × 500 bytes = 50 GB/month

Key design decision — short code generation:

Option A: Hash (MD5/SHA256, take first 7 chars)
  Pro: no central counter needed
  Con: collision handling adds complexity
 
Option B: Base62-encode auto-increment ID
  Pro: no collisions, deterministic
  Con: requires a central ID generator (use Snowflake or DB sequence)

Architecture:

Client → CDN → Load Balancer → Stateless App Servers
App Servers → PostgreSQL primary (writes) + read replicas (reads)
App Servers → Redis Cluster (URL cache + async click counters)
Analytics: flush Redis click counters to DB every 60 seconds

Use HTTP 301 for permanent redirects (browser-cached, reduces server load) or 302 if you need click analytics on every visit.

Canonical Problem 2 — Design Instagram#

Scale: 1B users, 100M daily active, 100M photos uploaded per day.

Photo storage: Store files in S3, not the database. Store the S3 URL in PostgreSQL.

Upload flow:

1. Client requests a presigned S3 URL from the API server
2. Client uploads directly to S3 (bypasses application servers)
3. S3 event triggers a Lambda → adds job to processing queue
4. Workers resize to 3 resolutions, extract EXIF metadata, update DB
5. CloudFront CDN serves all reads

News feed — push vs pull:

Use hybrid: push for users with <1M followers, pull for celebrities. Store precomputed feeds in Redis sorted sets (score = timestamp). Paginate with cursor, not offset.

Canonical Problem 3 — Design WhatsApp#

Scale: 100B messages per day = 1.1M messages/second.

Core insight: Use WebSockets (persistent connection) for real-time delivery. If the recipient is offline, store messages in a durable inbox and deliver on reconnect.

Message delivery states:

Sent → Delivered (double check) → Read (blue double check)

Database choice: Cassandra — partition key on chat_id, clustering key on message_timestamp DESC. Handles 1M+ writes/sec with linear horizontal scale. PostgreSQL cannot serve this write throughput on a single node.

Presence service: Clients send a heartbeat every 30 seconds. Presence state lives in Redis with a 60-second TTL. Contacts subscribe to each other's presence channels via Redis pub/sub.

Canonical Problem 4 — Design Netflix#

Video processing pipeline:

Raw upload → Transcoding farm
→ Encode H.264 / H.265 / AV1
→ Multiple resolutions: 240p through 4K
→ Adaptive bitrate (ABR) segments: 2–4 seconds each (HLS/DASH)
→ Store on Open Connect (Netflix's own CDN: 17,000+ servers inside ISPs)

Adaptive bitrate streaming: The player monitors download speed and buffer health every few seconds, switching quality seamlessly mid-stream.

Cold start <1 second: DNS resolves to the nearest Open Connect node. The player downloads the manifest file, buffers the first 2-3 segments, begins playback, and fetches the rest in the background.

Recommendation engine: Collaborative filtering + content-based models. Netflix runs A/B tests on thumbnail artwork per user segment — the same show may show 12 different thumbnails across its user base.

Canonical Problem 5 — Rate Limiter#

Common algorithms:

Distributed rate limiter with Redis: Use a Lua script for an atomic check-and-consume operation. Lua scripts in Redis execute atomically — no race conditions. Store (tokens, last_refill) per user key with a 1-hour TTL.

Headers to return:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 43
X-RateLimit-Reset: 1735689600
Retry-After: 30   (on 429 responses)

Canonical Problem 6 — Distributed Key-Value Store#

Consistent hashing: Distributes keys across N nodes using a hash ring. Use virtual nodes (150+ per physical node) to ensure even distribution and avoid hotspots when nodes join or leave.

Replication and quorum:

N = 3 replicas
W = 2 write quorum (confirmed by 2 nodes)
R = 2 read quorum (compare 2 nodes)
 
W + R > N  →  strong consistency
W = 1, R = 1  →  eventual consistency, maximum availability

Conflict resolution options:

• Last-Write-Wins (LWW): fast, loses concurrent updates
• Vector clocks: track causality, more complex
• CRDTs: mathematically merge-safe data types (DynamoDB uses this for some data types)

Real-world implementations: DynamoDB, Apache Cassandra, Redis Cluster.

Common Mistakes#

• Jumping into components before clarifying requirements. Always spend the first 5 minutes on functional and non-functional requirements. Ask: "Should I optimize for reads or writes? What consistency level is required?"
• Choosing a database without justification. "I'll use PostgreSQL" is incomplete. Say why: ACID compliance, complex joins, or existing team expertise.
• Ignoring failure modes. Interviewers want to hear: "What happens when this cache node goes down?" or "How do we handle a network partition?"
• Going too deep too early. Describing a perfect hash function algorithm before drawing the high-level box diagram wastes time and signals weak communication skills.
• Not estimating scale. Back-of-envelope math (writes per second, storage per year, cache size) anchors every decision and impresses interviewers.

Best Practices#

• Practice drawing diagrams on paper or Excalidraw before using a whiteboard in the interview.
• Say your assumptions out loud: "I'm assuming 99.9% availability SLA, which means <9 hours downtime per year."
• When the interviewer says "good, let's go deeper on X" — that is your signal. Redirect immediately.
• After proposing a solution, proactively identify its weaknesses: "The downside of this approach is..."
• Read engineering blogs from Netflix, Uber, Airbnb, Discord, and Figma. Real architectural decisions make better interview answers than textbook examples.

Key Takeaways#

• The RADIO framework (Requirements, API, Data Model, High-Level Design, Deep Dives) provides a repeatable structure for any system design interview.
• System design interviews evaluate trade-off reasoning and communication as much as technical correctness.
• Fan-out on write (push model) for news feeds gives fast reads but requires special handling for celebrity accounts with millions of followers.
• Cassandra is the preferred database for write-heavy workloads like messaging systems because it handles 1M+ writes/sec through horizontal partitioning.
• A distributed rate limiter uses Redis Lua scripts for atomic token-bucket check-and-consume operations, preventing race conditions in multi-instance deployments.
• Consistent hashing with virtual nodes distributes keys evenly across a cluster and minimizes key redistribution when nodes are added or removed.
• Netflix uses adaptive bitrate streaming (HLS/DASH) with 2-4 second segments, allowing the player to switch quality mid-stream based on real-time bandwidth.
• W + R > N in a distributed key-value store guarantees strong consistency; lowering either quorum trades consistency for higher availability.