System design interviews are the highest-signal rounds in senior engineering interviews — and the most feared. In 2026, FAANG and top-tier startups expect you to design systems like "Design a URL shortener," "Design a chat system," or "Design a rate limiter" from scratch in 45 minutes. This framework-based guide covers the repeatable approach, key building blocks, and the real evaluation criteria interviewers use.
The 4-Step System Design Framework
| Step | Time Budget | What to Do | Interviewer Looks For |
|---|
| 1. Requirements | 5 min | Clarify functional/non-functional reqs, estimates (DAU, QPS, storage) | Asking clarifying questions, scope management |
| 2. High-Level Design | 10 min | Draw major components, data flow, API design | Clean separation of concerns, reasonable APIs |
| 3. Deep Dive | 20 min | Pick 2-3 critical components, detail the data model, scaling strategy | Technical depth, trade-off reasoning |
| 4. Wrap-Up | 10 min | Identify bottlenecks, discuss scaling limits, suggest improvements | Bottleneck awareness, realistic scaling |
Back-of-the-Envelope Estimation
| Metric | How to Calculate | Example (Twitter-scale) |
|---|
| DAU (Daily Active Users) | Assume, then validate with interviewer | 200M DAU |
| QPS (Queries Per Second) | DAU × avg requests per user / 86,400 | 200M × 50 / 86,400 ≈ 115K QPS |
| Storage (per day) | QPS × avg data size × 86,400 | 115K × 1KB × 86,400 ≈ 10 TB/day |
| Bandwidth | Storage per second (MB/s) | 10 TB / 86,400 ≈ 120 MB/s |
| Cache Size | Daily storage × 0.2 (80-20 rule) | 10 TB × 0.2 = 2 TB cache |
Core Building Blocks for Any Design
| Problem | Solution | When to Use |
|---|
| Read-heavy workload | Cache (Redis) + Read replicas | Read:Write ratio > 10:1 |
| Write-heavy workload | Write-ahead log, async writes, sharding | Write QPS > 10K |
| Large data volume | Database sharding (consistent hashing) | Data > 1TB, single DB can't handle |
| Real-time updates | WebSocket + pub/sub | Chat, live feeds, notifications |
| File / image storage | Object storage (S3) + CDN | User uploads, media serving |
| Long-running tasks | Message queue (Kafka, SQS) + workers | Video processing, email sending, ML inference |
| Rate limiting | Token bucket / sliding window + Redis | API protection, DDoS prevention |
| Search | Elasticsearch or PostgreSQL FTS | Full-text search, filtering |
| Analytics | ClickHouse, BigQuery, data lake | Event tracking, reporting |
Common System Design Questions & Key Decisions
| System | Key Decision Points | Common Pitfall |
|---|
| URL Shortener | ID generation (Snowflake vs hash), redirect caching | Forgetting rate limiting for URL creation |
| Chat System | Long polling vs WebSocket, message ordering, read receipts | Not handling offline messages / message reliability |
| News Feed | Fan-out-on-write vs fan-out-on-read, feed ranking | Underestimating celebrity user fan-out cost |
| Rate Limiter | Token bucket vs sliding window, distributed vs centralized | Race conditions in distributed counters |
| Video Streaming | Transcoding pipeline, adaptive bitrate (HLS/DASH), CDN | Not discussing encoding formats and device compatibility |
Bottom line: System design interviews test breadth, not depth. The interviewer wants to see that you can decompose a complex system, identify the critical path, and make reasonable trade-offs. Master the 4-step framework, memorize the 10 core building blocks, and practice estimating QPS/storage quickly. The difference between a "pass" and "fail" is rarely technical accuracy — it is structured thinking and communication. See also: PostgreSQL Query Optimization and Full-Text Search Comparison.