The 6-Step Framework
Clarify → HLD → Data Model → Scale → Trade-offs → Bottlenecks
How to Tackle System Design Interviews
A 6-step framework used by senior engineers at FAANG. Follow this in every system design interview — it's structure over memorization. Total time: ~40 minutes.
The 6-Step Framework
Clarify Requirements
Never jump into design. Ask clarifying questions to understand scope. Split into functional and non-functional.
- ✓ Ask: who are the users? What's the primary use case?
- ✓ Estimate: QPS (read/write split), data size, storage growth
- ✓ Identify: read-heavy or write-heavy?
- ✓ Clarify: consistency vs availability requirements
- ✗ Don't assume — ask 'should tweets support images?'
- ✗ Don't skip scale estimation
- ✗ Don't forget to write requirements down
For 'design Twitter': Is it just text? Image/video? Real-time feed? How many users?
Draw the High-Level Design
Draw boxes and arrows. Start simple — client, load balancer, app servers, database. Show data flow.
- ✓ Start with: Client → LB → App → DB
- ✓ Add cache if read-heavy
- ✓ Add message queue if async processing needed
- ✓ Label every arrow
- ✗ Don't draw 20 boxes — keep it to 4-7 main components
- ✗ Don't commit to specific technologies yet
- ✗ Don't skip the CDN if there's static content
Twitter HLD: Client → API Gateway → [Tweet Service, Feed Service] → [DB, Cache, Queue].
Design the Data Model
Define the core entities and their relationships. Choose SQL vs NoSQL based on access patterns.
- ✓ List entities: User, Tweet, Follow, Like
- ✓ Define relationships
- ✓ Choose SQL (relational, ACID) or NoSQL (flexible, scalable)
- ✓ Show table/document schemas with keys
- ✗ Don't skip the primary key and indexes
- ✗ Don't ignore access patterns
- ✗ Don't forget to estimate storage
Twitter: users(id, name, email), tweets(id, user_id, text, created_at), follows(follower_id, followee_id).
Deep Dive: Scale the Design
Now make it scale. Address bottlenecks: single DB, hot keys, write throughput.
- ✓ Identify the bottleneck (usually the database)
- ✓ Shard by a good key (user_id hash)
- ✓ Add read replicas for read-heavy workloads
- ✓ Cache hot data (Redis) — specify TTL and eviction
- ✗ Don't shard before you need to
- ✗ Don't forget cross-shard queries are 10x slower
- ✗ Don't ignore hot keys
Twitter: shard tweets by user_id. Pre-compute feeds in Redis sorted sets. For celebrities, use fan-out-on-read.
Discuss Trade-offs
Every design decision has a trade-off. Articulate them explicitly.
- ✓ For each choice, say 'I chose X because Y. The alternative is Z, but...'
- ✓ Mention CAP trade-offs: CP or AP?
- ✓ Discuss consistency vs latency
- ✓ Talk about cost
- ✗ Don't say 'this is the best' — there's always a downside
- ✗ Don't forget operational complexity
- ✗ Don't ignore edge cases
Fan-out-on-write: fast reads but write amplification for celebs. Hybrid: best of both, more code.
Identify Bottlenecks & SPOFs
Call out single points of failure and how you'd fix them.
- ✓ List SPOFs: single DB primary, single LB, single cache
- ✓ For each, state the fix: replication, failover, multi-AZ
- ✓ Discuss disaster recovery: RPO and RTO
- ✓ Mention monitoring and alerting
- ✗ Don't say 'it won't fail' — everything fails
- ✗ Don't forget the network
- ✗ Don't ignore human error
Single Redis = SPOF. Fix: Redis Sentinel or Redis Cluster. Add circuit breaker.
Common Mistakes & How to Avoid Them
Quick Reference Cheat Sheet
| If the problem is... | Reach for... |
|---|---|
| Read-heavy system | Cache (Redis) + read replicas + CDN for static |
| Write-heavy system | Shard the DB + async writes (queue + batch) + LSM-tree DB (Cassandra) |
| Global latency | CDN + multi-region DB + edge compute |
| High availability | Multi-AZ + replication + automatic failover + health checks |
| Strong consistency | CP DB (Spanner) + quorum reads/writes + 2PC for cross-shard |
| Eventual consistency | AP DB (Cassandra) + async replication + conflict resolution (LWW/CRDT) |
| Search | Elasticsearch + denormalize + inverted index |
| Real-time updates | WebSocket / SSE + pub-sub (Redis/Kafka) |
| Large file storage | Object store (S3) + CDN + multipart upload |
| Time-series data | Column-family DB (Cassandra) + time-based partitioning + downsampling |