System design interviews are the most anxiety-inducing part of the senior engineering interview loop. Unlike coding problems with clear right/wrong answers, system design is open-ended and evaluates your engineering judgment. This roadmap provides a structured 30-day preparation plan, from foundational concepts to mock interviews, designed for engineers targeting senior (L5+) positions at top tech companies.
Week 1: Foundations (Days 1-7)
Build the vocabulary and mental models. Day 1-2: Networking basics — HTTP/1.1 vs HTTP/2 vs HTTP/3, TCP vs UDP, DNS resolution, TLS handshake, WebSocket, connection pooling. Understand how data moves between client and server. Day 3-4: Storage fundamentals — SQL vs NoSQL decision framework, B-tree indexes, LSM trees, ACID transactions, CAP theorem, consistency models (linearizability to eventual consistency). Understand when to use PostgreSQL vs DynamoDB vs Cassandra vs Redis. Day 5-6: Distributed systems primitives — consistent hashing, replication (synchronous vs async), sharding strategies, distributed consensus (Raft basics), leader election, distributed locks. Day 7: Caching and CDN — cache-aside pattern, write-through, eviction policies (LRU, LFU), cache stampede prevention, CDN architecture, origin shield. Study method: for each topic, understand the WHAT (what is it), WHY (why is it needed), and TRADEOFFS (what do you gain/lose). Do not just memorize — understand the reasoning so you can apply it to novel problems.
Week 2: Building Blocks (Days 8-14)
Learn the components you will assemble in designs. Day 8-9: Message queues — Kafka vs RabbitMQ vs SQS. When to use async vs sync. Dead letter queues. Exactly-once processing with idempotent consumers. Event-driven architecture. Day 10-11: API design — REST best practices, API versioning, pagination (cursor-based), rate limiting (token bucket), idempotency keys, GraphQL vs REST vs gRPC tradeoffs. Day 12-13: Observability — metrics (Prometheus, RED/USE), logs (structured logging, ELK vs Loki), traces (OpenTelemetry), SLI/SLO/SLA, error budgets, alerting on burn rate. Day 14: Back-of-envelope estimation — memorize key numbers (latency, throughput, storage sizes). Practice the estimation template: DAU -> RPS -> storage -> bandwidth -> infrastructure decisions. Do 3-5 estimations until the math is automatic. Study method: for each building block, know when to use it, how it works internally, and common pitfalls. Build a mental checklist: when do I need a cache? When do I need a message queue? When do I need a CDN?
Week 3: Classic Problems (Days 15-24)
Practice designing systems using the interview framework. Do 1 problem per day: Day 15: URL Shortener — the warm-up. Key generation, base62, caching, analytics. Day 16: Twitter/X News Feed — fanout-on-write vs read, celebrity problem, ranking. Day 17: Chat System (WhatsApp) — WebSocket, message delivery, group chat, E2E encryption. Day 18: Instagram — image upload pipeline, CDN, feed generation, Explore recommendations. Day 19: YouTube — transcoding, adaptive bitrate, CDN, recommendations, comments. Day 20: Uber/Lyft — driver location tracking, matching algorithm, surge pricing, ETA. Day 21: Notification System — multi-channel (push/email/SMS), fanout, rate limiting, delivery tracking. Day 22: Rate Limiter — token bucket, sliding window, distributed rate limiting with Redis. Day 23: Web Crawler — URL frontier, politeness, deduplication, recrawl strategy. Day 24: Google Maps/Search — geospatial indexing, routing algorithms, autocomplete. For each: follow the framework — 5 min requirements, 5 min estimation, 10 min high-level, 15 min deep dive, 5 min wrap-up. Time yourself. Practice explaining out loud (not just thinking).
Week 4: Advanced Topics and Mock Interviews (Days 25-30)
Day 25-26: Advanced topics — event sourcing and CQRS, saga pattern and outbox pattern for microservices, distributed transactions, multi-region architecture (active-active, RPO/RTO). Day 27-28: Mock interviews — practice with a friend or use a platform (Pramp, interviewing.io, Exponent). The person playing the interviewer should: ask follow-up questions, redirect to specific areas, and challenge your design decisions. Practicing WITH another person is 10x more valuable than practicing alone. Record yourself if possible — watch for: filler words, unclear explanations, and time management issues. Day 29: Review weaknesses — after mock interviews, identify areas where you struggled. Spend the day deepening your understanding of those topics. Common weak areas: database internals (how indexes actually work), consistency models (when to use what), and estimation (running out of time or making arithmetic errors). Day 30: Rest and review — skim your notes. Do one light practice problem. Get good sleep. Confidence matters in the interview — if you have done the preparation, trust the process.
Interview Day Checklist
During the interview: (1) Listen to the problem for 30 seconds before speaking. Understand what is being asked. (2) Clarify requirements (5 min). Write them down. (3) Do estimation (3-5 min). Let numbers guide your design. (4) Draw the high-level architecture (10 min). Cover the full system before going deep. (5) Pause and ask: “I can go deep on the database design or the caching strategy. Which interests you?” (6) Deep dive (15 min). State tradeoffs for every decision. (7) Address failure modes for 2-3 critical components. (8) Wrap up with extensions (monitoring, scaling, security). Communication tips: think out loud. The interviewer evaluates your reasoning process, not just the final design. If you are stuck: say so and explain your thinking. “I am not sure whether to use Kafka or SQS here. Let me think about the requirements — we need ordering, so Kafka partitions by key would work.” This demonstrates structured problem-solving even under uncertainty. What NOT to do: do not memorize designs. Interviewers detect rehearsed answers and will deviate with follow-up questions. Understand the WHY behind every decision so you can adapt.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What is the best 30-day plan for system design interview preparation?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Week 1 (Foundations): networking (HTTP, TCP, DNS, WebSocket), storage (SQL vs NoSQL, indexes, CAP theorem), distributed primitives (consistent hashing, replication, sharding, consensus), caching and CDN. Week 2 (Building Blocks): message queues (Kafka vs SQS), API design (REST, pagination, idempotency), observability (metrics, logs, traces, SLOs), back-of-envelope estimation (memorize key numbers, practice the template). Week 3 (Classic Problems): 1 problem per day — URL Shortener, Twitter Feed, WhatsApp, Instagram, YouTube, Uber, Notification System, Rate Limiter, Web Crawler, Google Maps. Follow the 45-minute framework for each. Practice explaining out loud. Week 4: advanced topics (event sourcing, saga pattern, multi-region), 2-3 mock interviews with another person, review weaknesses, rest before the interview.”}},{“@type”:”Question”,”name”:”What should you do during the system design interview itself?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Interview day checklist: (1) Listen for 30 seconds before speaking. (2) Clarify requirements (5 min) — write them down. (3) Do estimation (3-5 min) — let numbers guide architecture. (4) Draw high-level architecture (10 min) — cover the full system first. (5) Pause and ask which area to deep dive. (6) Deep dive (15 min) — state tradeoffs for every decision. (7) Address failure modes for 2-3 critical components. (8) Wrap up with extensions. Think out loud — the interviewer evaluates reasoning, not just the design. If stuck, say so and explain your thinking. Do NOT memorize designs — interviewers detect rehearsed answers and deviate with follow-ups. Understand the WHY so you can adapt.”}}]}