System Design Interview Cheat Sheet: The Framework That Gets You Hired at FAANG

System design interviews are not about having the right answer — they are about demonstrating how you think about engineering problems at scale. Interviewers at Google, Meta, Amazon, and Netflix are not looking for a perfect design. They are evaluating whether you scope problems correctly, make trade-offs explicitly, and know which tools to use for which problems. This framework is what consistently gets offers.

⚡ TL;DR: The 45-minute template: 5 min requirements, 5 min capacity estimation, 5 min API design, 10 min high-level design, 15 min deep dive on 2 components, 5 min trade-offs. Always drive the conversation — never wait for the interviewer to direct you.

The 45-minute framework

# STEP 1: Requirements (5 minutes)
# Functional requirements — what the system does:
# "Users can post tweets, follow other users, see a feed of followed users' tweets"

# Non-functional requirements — how it does it:
# Scale: DAU, requests/second, data volume
# Latency: read SLA, write SLA (e.g., feed loads in <100ms)
# Availability: 99.9% or 99.99%?
# Consistency: strong vs eventual?
# Durability: can we lose data?

# STEP 2: Capacity Estimation (5 minutes)
# Back of envelope — establish the scale of the problem:
# Twitter: 300M DAU, 1% post tweets, 99% read
# Writes: 300M × 0.01 × 3 tweets/day / 86400 = ~100 TPS
# Reads: 300M × 10 reads/day / 86400 = ~35,000 TPS
# Storage: 100 TPS × 280 chars × 86400 × 365 = ~900GB/year text
# This tells you: heavily read-skewed, need caching, writes much simpler

# STEP 3: API Design (5 minutes)
# Core endpoints only:
# POST /tweets { content: string } → { tweetId }
# GET /feed?userId&cursor&limit → { tweets: [], nextCursor }
# POST /follows { targetUserId } → 200
# Decisions: REST vs GraphQL? Pagination strategy? Authentication?

Database selection framework

# The right database for the right problem:

# Relational (PostgreSQL, MySQL, Aurora):
# Use when: ACID transactions, complex queries with JOINs,
#           schema is known and stable, consistency critical
# Examples: financial transactions, user accounts, orders

# Document (DynamoDB, MongoDB, Firestore):
# Use when: flexible schema, simple access patterns, need scale,
#           read/write by primary key, no complex joins
# Examples: user profiles, product catalogs, session data

# Wide-column (Cassandra, HBase):
# Use when: write-heavy, time-series data, analytics,
#           massive scale, known read patterns
# Examples: IoT sensor data, click streams, audit logs

# Key-value (Redis, Memcached):
# Use when: sub-millisecond latency, caching, sessions,
#           leaderboards, rate limiting, pub/sub
# Examples: session store, cache layer, distributed locks

# Search (Elasticsearch, OpenSearch):
# Use when: full-text search, faceting, relevance scoring,
#           log analytics, complex queries
# Examples: product search, log analysis, document search

# Graph (Neo4j, Neptune):
# Use when: relationship traversal, recommendations,
#           fraud detection, knowledge graphs
# Examples: social network recommendations, fraud rings

Scaling patterns reference

# Read scaling:
# 1. Caching (Redis): reduces DB reads by 90%+
# 2. Read replicas: horizontal read scaling
# 3. CDN: static assets, geographic distribution
# 4. Denormalization: precompute data to avoid joins

# Write scaling:
# 1. Queue-based (SQS, Kafka): absorb write spikes
# 2. Sharding: partition data across multiple DB instances
# 3. CQRS: separate write model from read model
# 4. Event sourcing: append-only log, derive state

# Compute scaling:
# 1. Horizontal: add more stateless instances
# 2. Load balancing: distribute traffic
# 3. Auto scaling: CloudWatch metrics → EC2 ASG
# 4. Serverless: Lambda for event-driven, spiky workloads

# Latency reduction:
# 1. Caching at every layer (CDN → API cache → DB cache)
# 2. Async processing: decouple slow operations
# 3. Indexing: query optimization
# 4. Edge computing: run logic closer to user

Worked example: Design Twitter Feed (30-second sketch)

# Requirements:
# - 300M DAU, 100 TPS writes, 35K TPS reads
# - Feed load <100ms, eventual consistency OK

# High-level:
# Write path: API → Tweet Service → DynamoDB (tweets) + Fanout Service → Redis (feeds)
# Read path: API → Redis cache (90% hit) → DynamoDB (10% miss)

# Feed generation strategies (trade-off):

# Push model (fanout on write):
# On tweet: write to all followers' feed caches immediately
# Read: just read from cache
# Pro: fast reads
# Con: celebrity with 10M followers = 10M writes per tweet

# Pull model (fanout on read):
# On tweet: just write the tweet
# On read: fetch followed users' recent tweets, merge, sort
# Pro: simple writes
# Con: slow reads for users following many people

# Hybrid (what Twitter actually uses):
# Push for regular users (<10K followers)
# Pull for celebrities (>10K followers) — merge at read time
# Interview signal: knowing this trade-off = senior-level answer

Common interview mistakes to avoid

• ❌ Starting to draw before clarifying requirements — always scope first
• ❌ Not estimating scale — the scale determines every architectural decision
• ❌ Over-engineering for requirements that were not stated
• ❌ Choosing a database without explaining the trade-off
• ❌ Not addressing failure modes — ask: “what happens when X fails?”
• ❌ Waiting for the interviewer to ask questions — you should drive
• ✅ State trade-offs explicitly: “I’m choosing X over Y because…”
• ✅ Acknowledge what you are NOT designing: “I would add auth here but won’t go deep”
• ✅ When stuck: “Let me think through the data flow from user request to response”

The architectures discussed here are all implemented in the URL shortener system design deep dive and the rate limiter design guide — both are canonical interview questions with full implementation detail. External reference: System Design Primer on GitHub.