System Design Interview Prep — A Practitioner's Last-Week Playbook

So, your recruiter just dropped the bomb: your system design interview is next week. Panic sets in. You haven't looked at a load balancer config in months, and you definitely haven't thought about how to scale a URL shortener since your last job hunt.

Breathe. As a senior systems engineer who has conducted dozens of these interviews, I can tell you a secret: we don't expect you to invent a novel distributed system in 45 minutes. We expect you to apply standard patterns to a vague problem and defend your trade-offs.

Here is the exact 7-day playbook to get you ready.

The 7-Day Countdown Plan

If you only have one week, you cannot read "Designing Data-Intensive Applications" cover to cover. You need high-ROI study.

Days 1-2: Core Components & Constraints

Stop trying to memorize architectures. Start memorizing the building blocks. You need to know the basic pros, cons, and use-cases for:

• Load Balancers: L4 vs L7, Nginx, HAProxy.
• Databases: SQL (Postgres) vs NoSQL (Cassandra for high write throughput, MongoDB for document storage, Redis for caching/speed).
• Message Queues: Kafka (event streaming, replayability) vs RabbitMQ (task queuing).
• Caching: Redis/Memcached, write-through vs write-behind, eviction policies.

Days 3-4: The "Big 5" System Design Interview Questions

80% of system design questions are variations of these five. Study them intensely:

1. Design a URL Shortener (TinyURL) — Teaches you about base62 encoding, read-heavy workloads, and caching.
2. Design a Chat System (WhatsApp) — Teaches you about WebSockets, long polling, and real-time data flow.
3. Design a Notification System — Teaches you about message queues, idempotency, and third-party integrations.
4. Design a Rate Limiter — Teaches you about distributed caching, Redis algorithms (Token Bucket, Sliding Window).
5. Design a Social Media Feed (Twitter/Instagram) — Teaches you about fan-out on write vs fan-out on read.

Days 5-6: The Framework

Never walk into a system design interview and just start drawing boxes. You will fail. Use a framework. In 45 minutes, you should spend:

• 5 mins: Requirements Clarification. Functional (what it does) and Non-Functional (scale, latency, availability).
• 5 mins: Back-of-the-envelope estimation. Traffic, storage, bandwidth. (Keep it simple: 1M DAU, what's the QPS?)
• 10 mins: High-level design. Draw the basic components. Client -> API Gateway -> App Servers -> DB.
• 15 mins: Deep dive. This is where the interview actually happens. The interviewer will pick a bottleneck. Fix it.
• 10 mins: Bottlenecks & Trade-offs. What happens if a node fails? How do you handle network partitions?

Day 7: Mock & Rest

Do a mock interview. If you don't have a friend, talk out loud to a wall. You need to get used to verbalizing your thought process while drawing.

The Practitioner's Edge: What Actually Differentiates You

Generic candidates say: "I'll put a cache here to make it faster."

Strong candidates say: "I'll use Redis as a look-aside cache for the user profiles since they are read-heavy and rarely updated. I'll set a TTL of 1 hour, and use an LRU eviction policy. If the cache goes down, the database can handle the degraded performance temporarily."

Always talk about trade-offs. There is no perfect system. If you choose strong consistency (SQL), acknowledge the latency hit. If you choose eventual consistency (Cassandra), acknowledge the user experience impact (e.g., seeing an old like count for a few seconds).