The 45-Minute Game Plan
[!TIP] Time is the Enemy: In a System Design interview, you have exactly 45 minutes to design a global-scale system from scratch. If you spend 20 minutes debating the database schema, you will fail because you missed the Deep Dive.
This checklist is your compass. It ensures you hit every required signal within the time limit. Think of it as a pilot’s pre-flight checklist—skip a step, and the system crashes.
Interactive Interview HUD
Use this Head-Up Display (HUD) during your practice sessions. It includes a mission timer, a Score Tracker, and a Latency Simulator to visualize the impact of your architectural choices.
Phase 0: Ice Breaker (0 - 5 Minutes)
Goal: Build rapport and signal communication skills. Why it matters: Interviewers judge your “soft skills” immediately. If you are arrogant, defensive, or ramble, you fail before you draw a box.
1. The Intro
- “Tell me about yourself.” -> Keep it to 2 minutes. Current role + One big technical win + Why you are here.
2. Behavioral Checks
- “Tell me about a time you disagreed with a PM.”
- “How do you handle technical debt?”
- Tip: Use the STAR method (Situation, Task, Action, Result). Focus on the Result (e.g., “Reduced latency by 50%”).
Phase 1: Requirements (5 - 10 Minutes)
Goal: Scope the problem and signal PRAGMATISM (see Phase 1 in our blueprint). Why it matters: Building the wrong system is worse than building no system. If you design a Twitter clone for 1,000 users instead of 1 billion, your architecture will be fundamentally wrong (e.g., using SQL JOINs for the feed).
1. Functional Requirements
Ask: “What are the core features?”
- Example (Twitter): Post tweet, View timeline, Search tweets.
- Exclude: Direct Messaging, Analytics (unless asked).
2. Non-Functional Requirements
Ask: “What is the scale?”
- DAU: 100 Million? 1 Billion?
- Read/Write Ratio: Is it read-heavy (Twitter) or write-heavy (IoT logging)?
- Consistency: CAP Theorem. Do we need strong consistency (Payments) or eventual consistency (Social Feed)?
- Latency: Is < 200ms acceptable for feed generation?
3. Back-of-Envelope Math
Show your work.
- QPS:
DAU * Requests_Per_Day / 86400.- Tip: 1M requests/day ~= 12 QPS.
- Storage:
New_Data_Per_Day * 365 days * 5 years.
🚩 RED FLAGS & THE RABBIT HOLE (PHASE 1)
Don't fall into the Rabbit Hole Trap shown in our blueprint—keep math brief.
- Starting the design without asking about scale (DAU/QPS).
- Drawing a database immediately.
- Assuming a monolith vs microservices without discussion.
- Saying "I'll use a Load Balancer" without knowing if it's L4 or L7.
Phase 2: High Level Design (10 - 20 Minutes)
Goal: Lay the foundation and signal BROAD KNOWLEDGE (Phase 2 in the blueprint). Why it matters: This proves you understand the “Big Picture” before diving into the weeds. It establishes the data flow and the major components.
1. API Design
Define the contract using REST or gRPC.
POST /tweets
body: { user_id, content, media_ids }
GET /feed/{user_id}
query: { page_size, next_cursor }
2. Database Schema
Choose your weapon carefully.
- SQL (PostgreSQL/MySQL): Structured data, complex joins, transactions (e.g., Billing).
- NoSQL (Cassandra/DynamoDB): Massive scale, simple lookups, flexible schema (e.g., Feed, Messages).
[!TIP] Justify your choice. “I’m choosing Cassandra for the timeline because we need high write throughput and don’t need complex joins.”
3. The Diagram
Draw the “Sunny Day” flow.
- Client -> Load Balancer -> Web Server -> Application Service -> Database.
🚩 RED FLAGS (NO HIRE)
- Using a single DB for a global scale system without discussing replication.
- Forgetting Load Balancers.
- Creating an API that returns all data (no pagination).
- Drawing arrows in the wrong direction (Arrows should follow the request).
Phase 3: Deep Dive (20 - 40 Minutes)
Goal: Prove you can scale and signal TECHNICAL DEPTH (Phase 3 in our blueprint). This is where you pass or fail.
Identify the bottlenecks in your HLD and fix them.
1. Scaling Reads
- Caching: Add Redis/Memcached. Discuss eviction policies (LRU/LFU). See Caching 101.
- Replication: Master-Slave architecture. Read from slaves.
- CDN: Serve static assets (images/videos) from edge locations.
2. Scaling Writes
- Sharding: How do you split the data?
- Sharding by UserID: Hot partitions for celebrities?
- Sharding by TweetID: Scatter-gather?
- See Sharding Strategies.
- Async Processing: Use a Message Queue (Kafka) to decouple writes and handle spikes.
3. Reliability
- Single Points of Failure: What if the Master DB dies? (Promote Slave).
- Circuit Breakers: Prevent cascading failures.
- Rate Limiting: Protect your services from abuse.
🚩 RED FLAGS (NO HIRE)
- "Magically" solving problems with "Add a Cache" (must explain eviction/consistency).
- Ignoring Single Points of Failure (SPOF).
- Unable to explain how Sharding actually works (Consistent Hashing vs Modulo).
Phase 4: Wrap Up (40 - 45 Minutes)
Summarize and signal SELF-AWARENESS (Phase 4 in our blueprint). Why it matters: This shows you are self-aware. No system is perfect. Admitting flaws is better than pretending they don’t exist.
- “We designed a system that handles 100M DAU.”
- “We used Cassandra for write scale and Redis for read latency.”
- “A potential bottleneck is the fan-out service, which we could optimize with a hybrid push/pull model.”
The Leveling Guide
What is the interviewer looking for?
Junior / Mid-Level (L3/L4)
- Goal: “Can they build a system that works?”
- Signals: Knows basic components (LB, Cache, DB). Can sketch a diagram.
- Anti-Patterns: Struggles with basic math. Does not know when to use SQL vs NoSQL.
Senior (L5)
- Goal: “Can they scale the system and handle failure?”
- Signals: Proactively identifies bottlenecks. Discusses trade-offs deeply (e.g., “Cassandra write amplification vs Read repair”). Handles failure modes (what if Redis dies?).
- Anti-Patterns: Designing only for the “happy path”.
Staff / Principal (L6+)
- Goal: “Can they define the problem and lead the team?”
- Signals:
- Challenges requirements: “Do we really need strong consistency here, or is causal consistency enough?”
- Simplifies complexity: “We don’t need a distributed cache here; a local memory cache on the app server is sufficient and faster.”
- Mentors the interviewer: “Have you considered this edge case?”
- Business Awareness: “This architecture is cheaper to run on spot instances.”
- Anti-Patterns: Over-complicating the design to show off.
5 Questions to Ask Your Interviewer
At the end, you have 5 minutes. Do not waste it.
- “What is the on-call load like for this team?” (Shows you care about operational excellence).
- “How does the team handle technical debt? Is there a dedicated quota?” (Shows pragmatism).
- “What is the biggest technical challenge the team is facing right now?” (Shows interest in real problems).
- “How are architectural decisions made? Is there an RFC process?” (Shows you value consensus).
- “What does success look like in the first 6 months for this role?” (Shows you are goal-oriented).