20 complete system designs — each with requirements, capacity estimation, architecture, database design, scaling strategy, and tradeoff analysis.
How to use this module: First, spend 35 minutes designing each system yourself without looking at the solution. Then compare. The thinking process matters more than the answer. Interviewers are evaluating your reasoning, not whether you got the "right" answer.
Option 1 — Hash the URL: MD5(longURL) → take first 7 chars → base62 encode. Problem: collisions (different URLs same hash prefix). Need to handle collision with a suffix.
Option 2 — Auto-increment ID: DB auto-increment ID → base62 encode. 7 chars of base62 = 62⁷ = 3.5 trillion URLs. Simple, no collisions. Problem: IDs are predictable (enumerable). Use a counter + shuffle bits.
Option 3 — Pre-generate keys (Twitter Snowflake style): Generate all 7-char keys in advance, store in a Key DB. Assign on request. Eliminates hotspot on ID generation. Used in production.
Videos are split into 2–10 second segments. The player downloads a manifest file (HLS/DASH) listing all available quality levels. Based on network speed, it dynamically switches between qualities mid-stream. If bandwidth drops, it switches to 360p. If it improves, it switches back to 1080p — seamlessly.
99% of views are on videos uploaded >24h ago. Pre-warm CDN edge nodes with popular videos. New video uploads go to origin, then are pushed/pulled to CDN as popularity grows. Long-tail videos stay on origin storage (rarely accessed, no need to cache everywhere).
For a group of 1000 members: when a message is sent, the server must deliver to all 1000 members. Fan-out approaches:
WhatsApp uses the Signal Protocol. Each device has a public/private key pair. Messages are encrypted with the recipient's public key. Only the recipient's private key can decrypt. WhatsApp servers see only encrypted bytes — even they cannot read your messages.
The challenge: Given a rider's location, find all available drivers within 5km — in milliseconds, updated every 4 seconds, for 3M drivers globally. A naive SQL query WHERE distance(lat,lon, driver_lat, driver_lon) < 5000 requires computing distance for every driver — O(3M) per request.
Solution: Geohash / S2 cells. Divide the world into a grid. Each cell has an ID. A driver at lat/lon belongs to cell "9q8yy". "Find nearby drivers" = "find all drivers in cell 9q8yy and adjacent cells" — a simple key lookup.
Surge multiplier = f(demand/supply in geohash cell). Computed every 5 minutes. Demand = ride requests. Supply = available drivers. If demand/supply > threshold → trigger surge. Multiplier increases until supply meets demand (higher price attracts more drivers). Implemented as a background job, result stored in Redis by geohash.
Fan-out on write (push model): When a user posts, push to all followers' feed caches immediately. Reading your feed is fast (pre-computed). Problem: a celebrity with 100M followers posting = 100M cache writes. Celebrities can't use push model.
Fan-out on read (pull model): When you open your feed, fetch the latest posts from everyone you follow. Merge and rank. Problem: if you follow 5000 people, you need 5000 DB reads per feed load. Too slow.
Hybrid (Instagram's actual approach): Regular users: push model (pre-computed feed). Celebrity users: pull model on read, merged with your pre-computed feed. Best of both worlds.
Store follow relationships in a graph-like structure. For feed generation, you need: "give me the user IDs of everyone that user 123 follows." Use a column-family DB (Cassandra) or denormalised Redis set. Avoid JOINs on a large social graph — they don't scale.
SET sent:{notifId} 1 NX EX 86400. NX = only set if not exists. If already set, skip sending.-- Lua script (atomic in Redis):
local key = "ratelimit:" .. user_id .. ":" .. endpoint
local limit = 100 -- 100 requests
local window = 60 -- per 60 seconds
local now = tonumber(redis.call('TIME')[1])
local count = redis.call('INCR', key)
if count == 1 then
redis.call('EXPIRE', key, window)
end
if count > limit then
return 0 -- rate limited
end
return 1 -- allowedThe 35-minute framework interviewers use at FAANG: Requirements (5 min) → Capacity estimation (3 min) → High-level design (10 min) → Deep dive on 2-3 components (15 min) → Wrap up: tradeoffs, bottlenecks, improvements (2 min)