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 Cheat Sheet

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 (Transport) vs L7 (Application) load balancing. Popular algorithms like Round Robin and Least Connections.
• Caching: Redis/Memcached. Strategies like write-through, write-behind, and cache eviction policies (LRU, LFU).
• Databases & Scaling: SQL vs NoSQL. Understand Vertical Scaling (adding CPU/RAM) vs Horizontal Scaling (Sharding/Partitioning, using Consistent Hashing to minimize rebalancing).
• CAP Theorem: The fundamental trade-off in distributed data stores. You must choose two between Consistency, Availability, and Partition Tolerance (usually AP or CP in the real world).
• Concurrency & DB Isolation: ACID properties, Transaction isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable), and the differences between Optimistic vs. Pessimistic concurrency control.

For hands-on practice with these components, try the Backend interview questions in our question bank — they cover database trade-offs, caching strategies, and distributed system fundamentals.

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

80% of system design questions are variations of these five. Study them intensely and understand their core architectures:

1. Design a URL Shortener (TinyURL) — Base62 encoding vs MD5. Use a Distributed Coordination Service (like Zookeeper) for a reliable counter approach. Key components include a Key Generation Service, a Key-DB for storage, and a robust caching layer for read-heavy workloads.
2. Design a Chat System (WhatsApp) — Focus on WebSockets for persistent connections, client-initiated communication protocols, and a dedicated Message Service. Messages in transit must be held securely, often utilizing a robust notification service.
3. Design a Social Media Feed (Twitter/Instagram) — The classic read-heavy architecture. Understand the async fan-out approach for timelines, aggressively caching timelines in a Redis cluster, and balancing push vs pull models based on celebrity status (hybrid approach).
4. Design a Notification System — Teaches you about message queues (Kafka, RabbitMQ), idempotency (preventing duplicate notifications), and third-party integrations (APNs, FCM).
5. Design a Rate Limiter — Teaches you about distributed caching and standard algorithms (Token Bucket, Sliding Window Log, Sliding Window Counter).

Companies like Google and Stripe are known to ask variations of these problems in their system design rounds — check our company-specific guides for insider context on what they emphasise.

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).

For more on how this plays out in real interview loops, see our Amazon interview prep guide — Amazon interviewers are particularly rigorous about trade-off discussions in their system design rounds.