Backend7 min read

System Design Interview

Ace system design - URL shortener, Twitter feed, rate limiter, distributed cache, and key patterns for designing systems at scale.

System DesignScalabilityLoad BalancingDatabase ShardingDistributed Systems

skill: System Design Interview category: Backend tags: [System Design, Scalability, Load Balancing, Database Sharding, Distributed Systems] readingTime: 7

System design is about trade-offs, not perfect answers. Interviewers want to see that you clarify requirements before designing, make explicit trade-offs, know the rough numbers (QPS, storage, bandwidth), and know which patterns solve which problems. Don't jump to complex solutions - start simple, then scale.

Workflow

Clarify requirements and estimate scaleThe same feature for 1K users vs. 100M users requires completely different designs. Nail the scale before drawing any boxes.
Design a URL shortenerThe URL shortener is the "Hello World" of system design - it teaches hashing, caching, redirection, and scale trade-offs in one concise problem.
Design a rate limiterRate limiters are asked frequently - the answer reveals knowledge of sliding windows, distributed counters, and the cost of precision vs. approximation.
Design a news feed (Twitter/Instagram)The news feed problem teaches fan-out patterns, celebrity accounts, cache invalidation, and the trade-off between write time and read time complexity.
Apply consistent hashing for shardingDatabase sharding distributes data across nodes. Consistent hashing minimizes data movement when nodes are added or removed - only 1/N fraction of keys remaps.

Output Format

System design: clarify requirements + estimate QPS/storage, URL shortener with Redis cache + base62 hash, Redis sliding window rate limiter, hybrid fan-out news feed, consistent hashing for sharding.

Step 1: clarify functional reqs + scale (QPS, storage, read:write ratio)
Step 2: API design (endpoints, request/response)
Step 3: data model (tables, indexes)
Step 4: high-level design (load balancer → app → cache → DB)
Step 5: deep dive (caching, sharding, edge cases)

Examples

Input

Output

Edge Cases & Gotchas

Hot shards in consistent hashing - If one user has 100M followers, all their posts hash to one shard. Add shard-level rate limiting and read replicas for hot keys.
Cache stampede at peak traffic - Popular content cache expires simultaneously → all requests hit DB. Use staggered TTLs or probabilistic early refresh to prevent thundering herd.
Cross-datacenter replication lag - For global systems, users in different regions read from local replicas. Write → primary → async replication to replicas adds 50-200ms lag. Inform the interviewer which operations need strong vs. eventual consistency.
Single point of failure - Every design should address SPOF. Load balancers need HA pairs, databases need replicas, caches need Redis Cluster. Ask: "What happens when this box fails?"

When to Break These Rules

Start simpler: most production systems at early stage don't need consistent hashing or fan-out on write - start with a single DB + Redis cache, add complexity when measured data demands it.
Acknowledge trade-offs explicitly in interviews rather than trying to design a perfect system - interviewers want to hear your reasoning, not a textbook answer.

Reference Files

https://bytebytego.com/
https://github.com/donnemartin/system-design-primer