System Design
System design is where SDE 2 interviews are won or lost. Use the STAR-D framework. Think in trade-offs, not just solutions.
Fundamentals & Numbers
Latency numbers, availability SLAs, CAP theorem, estimation formulas, database comparison, caching strategies
URL Shortener
Base62 encoding, hashing collision, read-heavy caching, 301 vs 302 redirect, expiry
Twitter / News Feed
Fan-out on write vs read, celebrity problem, feed ranking, sharding tweets
Rate Limiter
Token bucket, leaky bucket, fixed window, sliding window log & counter
Distributed Cache
Redis vs Memcached, eviction policies, cache-aside, write-through, thundering herd
Notification System
Multi-channel delivery, deduplication, retry logic, priority queues, device token management
// SDE 2 System Design Interview Tips
Always clarify: functional requirements (what it does) and non-functional (scale, latency, availability, consistency). Never skip this step.
Say it explicitly: 'I'll assume 100M DAU, 10:1 read-write ratio, p99 latency < 200ms'. Interviewers want to see how you think about constraints.
There's no perfect design. Every choice has a trade-off. 'I'm choosing eventual consistency here because it gives us better write throughput at the cost of stale reads for ~100ms.'
Proactively say 'The database is the bottleneck here. I'd add read replicas first, then shard if needed.'
Don't jump to distributed immediately. Single server → vertical scale → horizontal scale → sharding → microservices.
Instant recall: 1 million = 10⁶, 1B = 10⁹. 100K seconds/day. 10TB for 1B 10KB records. See Fundamentals page.