What's Inside
Concept 1
The 45-Minute Answering Framework
Your Blueprint for Every System Design Interview
A system design interview is not a test of whether you can design the perfect system. It is a test of how you think, communicate, and make decisions under constraints. The interviewer wants to see your thought process: how you break down ambiguity, how you make trade-offs, and how you justify your decisions. The 45-minute framework gives you a repeatable structure that ensures you cover all the important areas without getting stuck on any one.
Most candidates fail not because they lack knowledge, but because they lack structure. They jump into drawing a database schema without understanding the requirements, or they spend 20 minutes on one component and never discuss caching or scaling. The framework prevents these mistakes by giving you a clear time budget for each phase.
Requirements & Scope — 5 Minutes
This is the most important phase. You are establishing what the system does (functional requirements) and how well it must do it (non-functional requirements). The interviewer deliberately leaves the problem vague. Your job is to ask questions that narrow the scope to something designable in 40 minutes.
Ask about the core features and explicitly confirm which are in scope and which are not.
- URL shortener: "Can users create short URLs? Do we need custom aliases? Analytics? Expiration? Deletion?"
- Chat system: "One-on-one or group chat? File sharing? Read receipts? Online presence?"
List 4–6 features. The interviewer will say "focus on X and Y, skip Z." This is exactly what you want — a narrowed scope.
These questions determine your architecture. Ask: "How many users? How many requests per second? What latency is acceptable? Do we need 99.9% or 99.99% availability? Is this global (multi-region) or single region? What is the read-to-write ratio?" The answers drive every subsequent decision: a system with 100 QPS is architecturally different from one with 1 million QPS.
Back-of-Envelope Estimation — 3 Minutes
Estimation demonstrates that you think quantitatively about systems. The interviewer does not care if your math is exactly right — they care that you can reason about scale. Round aggressively: 86,400 seconds/day ≈ 105. A correct order of magnitude is all you need.
| What to Estimate | Formula | Why It Matters |
|---|---|---|
| QPS | Total ops/month ÷ 2.5M seconds. Separate reads & writes. Multiply by 2–3× for peak. | Determines server & database capacity. Is this read-heavy or write-heavy? |
| Storage | Avg object size × number of objects × retention period. | Determines whether one DB suffices or sharding is needed. |
| Bandwidth | QPS × avg response size. | Usually not a bottleneck, but critical for media-heavy systems. |
| Cache Memory | 80/20 rule: cache top 20% of daily data. 20% of daily QPS × avg object size. | Determines cache instance size (fits in Redis or needs cluster?). |
The conclusion matters more than the math. After estimation, always say: "This system is read-heavy (100:1 read-to-write ratio), so I'll optimize for reads with aggressive caching and read replicas." or "At 500 writes/sec, a single primary handles it. At 5,000 writes/sec, we need sharding."
High-Level Design — 10 Minutes
This is where you draw the architecture. Start with the universal template (Client → CDN → Load Balancer → API Servers → Cache + Database + Queue) and customize it for your specific system. Explain each component's role as you draw it. The interviewer should be able to follow the data flow from client to storage and back.
| Component | Role | Key Point to Mention |
|---|---|---|
| Clients | Entry point. Web, mobile, or both. | REST vs WebSocket vs GraphQL — which and why. |
| CDN | Caches static assets at the edge. | 80–90% latency reduction for static content. Mention for any media. |
| Load Balancer | Distributes traffic. Health checks remove unhealthy instances. | Least Connections algorithm for most systems. |
| API Servers | Handle request processing. Stateless. | Stateless = any server handles any request. Session data in Redis. |
| Cache (Redis) | Sub-millisecond reads for hot data. | Cache-aside pattern, TTL, LRU eviction policy. |
| Database | Source of truth. | SQL vs NoSQL reasoning, replication topology, sharding decision. |
| Message Queue (Kafka) | Decouples heavy/async operations. | Specific use case: order events, notifications, analytics, cache invalidation. |
| Background Workers | Consume from queue. Process async tasks. | Video encoding, email sending, analytics aggregation, search indexing. |
Deep Dive — 15 Minutes
This is where you demonstrate depth. You cannot cover everything in 15 minutes, so pick the 2–3 most critical areas for THIS specific system and go deep. The interviewer may guide you ("Tell me more about the database design") or let you choose. Either way, show specific knowledge: schema design, index strategy, caching patterns, queue configuration, consistency trade-offs.
- DB Schema: Actual table names, columns, data types. Mention which columns are indexed and why. Composite indexes for common query patterns.
- Caching: What key, what value, what TTL, what eviction policy. How do you handle cache invalidation and hot keys?
- Queue: Topic name, partition key, consumer group, retry policy, DLQ threshold.
- Consistency: Which operations need strong consistency? Which can be eventual? Why?
- Failure Handling: What happens if the primary DB goes down? How long does failover take? What is the RPO/RTO?
Saying "I'd use Redis for caching" without saying what you cache, what the key looks like (url:{shortcode}), the TTL (1 hour), and why (80% of reads hit 20% of URLs). Vague answers signal shallow knowledge. Specific answers signal production experience.
Concept 2
Must-Know Topics & Knowledge Map
The System Design Knowledge Map
System design interviews test breadth (do you know all the building blocks?) and depth (can you design one block in detail?). The knowledge map below covers the 12 topics that appear in virtually every interview. Classes 2–8 covered the first 8 in depth. This class focuses on how to synthesize them into a coherent answer under time pressure.
Top 24 Interview Questions by Category
The top 5 most frequently asked system design questions (covering ~60% of interviews) are: URL Shortener, Chat System (WhatsApp/Slack), News Feed (Instagram/Twitter), Rate Limiter, and Notification System. If you can confidently design these five, you have a strong foundation. The patterns you learn from these five transfer to virtually every other question.
- URL Shortener → teaches hashing, key generation, read-heavy caching, redirect logic
- Chat System → teaches WebSockets, presence, fan-out, message ordering
- News Feed → teaches fan-out on write vs read, celebrity problem, timeline pagination
- Rate Limiter → teaches token bucket, sliding window, Redis counters, distributed coordination
- Notification System → teaches Kafka fan-out, per-channel queues, deduplication, retry/DLQ
Concept 3
Scoring Rubric & Communication
How Interviewers Evaluate You
Understanding the rubric changes how you approach the interview. Most FAANG companies evaluate system design across five dimensions, each with a different weight. Notice that detailed design and trade-offs together account for 45% of your score — this is where depth and justification matter most. Communication alone is 10%, but poor communication can tank every other dimension.
- You drive the conversation without the interviewer needing to prompt you. You move from requirements → estimation → HLD → deep dive naturally.
- You explain trade-offs for every decision: "I chose PostgreSQL over Cassandra because we need ACID transactions for payments. The trade-off is that writes are slower, but at 40 writes/sec, a single primary handles it."
- You proactively mention failure scenarios: "What if the primary database goes down? I have a read replica that auto-promotes within 60 seconds. During that window, writes are rejected but reads continue."
- You discuss monitoring: "I'd monitor queue depth, p99 latency, error rate, and cache hit rate. If queue depth exceeds 1,000, auto-scaling adds workers."
- You use specific numbers and technologies: "Redis with allkeys-lru eviction, 16 GB, caching the top 20% of daily URLs with a 1-hour TTL." Not "some cache."
- You start designing without asking any clarifying questions.
- You cannot produce a working high-level architecture (no diagram, no data flow).
- You do not mention caching, queuing, or any non-trivial infrastructure.
- You cannot explain WHY you made a decision (just "I'd use Redis" without explaining the pattern, TTL, or eviction policy).
- You ignore the interviewer's hints (they are trying to help you).
Interview Behaviour Guide
Your Answer Template: Phrases to Use
These phrases are not scripts to memorize word-for-word. They are conversation openers that signal to the interviewer which phase you are in and that you are following a structured approach. Adapt them to each specific question, but use the same structure every time. The consistency of your framework is what makes you appear confident and organized.
- Requirements: "Before I start designing, let me ask a few clarifying questions to make sure I understand the scope..."
- Estimation: "Let me do a quick back-of-envelope to understand the scale we're dealing with..."
- HLD: "I'll start with a high-level architecture. At the top level, I'm thinking [Client → CDN → LB → API → DB]. Let me explain each component..."
- Deep Dive: "The most interesting part of this system is [X]. Let me go into more detail here..."
- Trade-offs: "I chose [X] over [Y] because [reason]. The trade-off is [downside], but at our scale that's acceptable because [justification]..."
- Wrap-up: "To summarize: I designed a system that handles [scale] with [key architectural decisions]. The main trade-offs are [X vs Y]. If given more time, I'd explore [Z]..."
Summary
Pre-Class Cheat Sheet
| Area | Key Takeaway |
|---|---|
| Framework | 6 phases in 45 minutes. Drive the conversation. Don't wait to be guided. |
| Requirements | Ask 5–8 clarifying questions before designing. Functional + non-functional. Narrowing scope is the #1 differentiator. |
| Estimation | QPS, storage, bandwidth, cache. Round aggressively. Always state the conclusion: read-heavy? write-heavy? does this need sharding? |
| HLD | Universal template: Client → CDN → LB → API Servers → Cache + DB + Queue → Workers. Customize. Explain each role. |
| Deep Dive | Pick 2–3 critical areas. Concrete schemas, algorithms, configs. Specific > vague. |
| Must-Know Topics | 12 topics. Master first 8 for FAANG. Top 5 questions: URL Shortener, Chat, News Feed, Rate Limiter, Notification. |
| Scoring | Problem Exploration 20%, HLD 25%, Detailed Design 25%, Trade-offs 20%, Communication 10%. Strong Hire = drives + deep trade-offs + mentions failures + monitoring. |
Want to Land at Google, Microsoft or Apple?
Watch Pranjal Jain's free 30-min training — the exact GROW Strategy that helped 1,572+ engineers go from TCS/Infosys to top product companies with a 3–5X salary hike.