Chapter 3 Flashcards - Interview Framework
flashcards volume1 framework essential
The 4-Step Framework
What are the 4 steps of the system design interview framework?
?
Step 1: Understand the problem and establish design scope (3-10 min). Step 2: Propose high-level design and get buy-in (10-15 min). Step 3: Design deep dive (10-25 min). Step 4: Wrap up (3-5 min).
What is the goal of Step 1 (Understand the problem)?
?
Clarify requirements and agree on scope with interviewer. Ask clarifying questions, define functional and non-functional requirements, write down assumptions, and get interviewer buy-in.
What are examples of clarifying questions to ask in Step 1?
?
Traffic volume? (How many users/requests?). Data retention? (How long to store?). Features? (What’s in scope for MVP?). Availability? (99.9%? 99.99%?). Consistency? (Strong or eventual?). Latency requirements? (p99 < 100ms?).
What are functional requirements vs non-functional requirements?
?
Functional: What features the system needs (e.g., post tweets, follow users, view timeline). Non-functional: Quality attributes like scale (100M DAU), performance (p99 < 1s), availability (99.9%), consistency (eventual OK), and durability (no data loss).
What is the goal of Step 2 (High-level design)?
?
Draw initial architecture and validate approach with interviewer. Start simple then iterate, draw diagrams, do back-of-envelope calculations, design APIs, define data model, and get agreement before proceeding.
What should you include in a high-level design diagram?
?
Basic components: Client, Load Balancer, Web Servers, Cache, Database, Message Queue (if needed), CDN (if needed). Show data flow with arrows, label components clearly, include protocols (HTTP, TCP, etc).
What is the purpose of back-of-envelope estimation in Step 2?
?
Shows quantitative thinking, validates design decisions, identifies potential bottlenecks, demonstrates you understand scale. Calculate QPS (queries per second), storage needs (daily/yearly), and bandwidth requirements.
How do you calculate QPS from daily active users?
?
Formula: (DAU × actions per user per day) / 86,400 seconds (or ~100K for easy math). Example: 100M DAU × 10 actions = 1B actions/day = 1B / 100K = 10K QPS. Don’t forget to multiply by 2-3x for peak traffic!
What is the goal of Step 3 (Deep dive)?
?
Drill into specific components based on interviewer’s interest. Ask what to focus on, discuss 2-3 components in detail, explain trade-offs for every decision, mention alternatives and when they’d be better.
What are common deep dive topics in system design interviews?
?
Scalability (how to handle 10x, 100x growth?), Performance (optimize latency?), Reliability (handle failures?), Consistency (strong vs eventual?), Security (auth, rate limiting?), Data storage (SQL vs NoSQL, sharding, replication?).
Why is discussing trade-offs critical in Step 3?
?
Every design decision has pros and cons. Interviewers want to see you understand there’s no perfect solution. Shows depth of knowledge, experience with real systems, and ability to make informed choices. Always present alternatives!
What should you discuss in Step 4 (Wrap up)?
?
Identify bottlenecks (at what scale will it break?), discuss failure scenarios (what if X fails?), monitoring and metrics (what to track?), next steps and enhancements (future improvements?), scale refinement (cost estimates?).
What are the most important communication tips for system design interviews?
?
Do: Think out loud, ask questions, be open to feedback, manage time, draw clearly, state assumptions. Don’t: Stay silent, jump to code, over-engineer, argue with interviewer, say “I don’t know” and stop, fixate on one solution.
What is the biggest mistake candidates make in system design interviews?
?
Not gathering requirements first - jumping straight to the design without asking clarifying questions. Always start with Step 1! Other common mistakes: too detailed too early, no trade-off discussion, ignoring scale, silent designing, no failure handling.
How should you manage time in a 45-minute system design interview?
?
Step 1 (Requirements): 3-10 min. Step 2 (High-level): 10-15 min. Step 3 (Deep dive): 10-25 min. Step 4 (Wrap up): 3-5 min. Don’t spend 30 min on one component - keep moving forward through all steps!
Functional vs Non-Functional Requirements
What functional requirements should you clarify for a URL shortener?
?
Can users create custom short URLs? Do shortened URLs expire or last forever? Should we track analytics (click counts, user agents, locations)? Can users delete URLs? Is user authentication required?
What non-functional requirements should you clarify for a URL shortener?
?
Scale: How many URLs shortened per day? (100M?). Traffic: What’s the read/write ratio? (10:1? 100:1?). Latency: How fast should redirection be? (< 100ms?). Availability: What uptime? (99.9%?). Retention: How long to keep URLs? (Forever? 5 years?).
What’s the difference between MVP scope and full product scope?
?
MVP: Core features only, simplest implementation, good enough for launch. Full product: All nice-to-have features, optimizations, scale to billions. In interviews, start with MVP then discuss how to scale. Don’t over-engineer initially!
API and Data Model Design
How should you design APIs in Step 2?
?
Define 2-3 core endpoints (not all), use REST or RPC style, specify request/response formats (JSON usually), include key parameters, mention HTTP methods (GET, POST, PUT, DELETE), keep it simple initially.
What should you include in a data model design?
?
Key entities (users, posts, etc.), relationships between entities (foreign keys), primary keys and indexes, storage choice (SQL vs NoSQL?), justification for choice, consider scale and query patterns.
Trade-offs and Alternatives
What are the trade-offs between SQL and NoSQL databases?
?
SQL: Pros - ACID transactions, structured data, easy joins, complex queries. Cons - harder to scale horizontally, fixed schema. NoSQL: Pros - horizontal scaling, flexible schema, high write throughput. Cons - eventual consistency, limited queries, no joins. Choice depends on consistency needs and scale.
What are the trade-offs between cache-aside and write-through caching?
?
Cache-aside: Read from cache, if miss then DB then cache. Pros - only cache what’s needed. Cons - cache miss penalty. Write-through: Write to cache, cache writes to DB. Pros - cache always consistent. Cons - write latency (two writes). Choose based on read/write patterns.
What are the trade-offs between push and pull for real-time updates?
?
Push (WebSockets, SSE): Server pushes to client. Pros - low latency, truly real-time. Cons - server maintains connections, doesn’t scale well. Pull (HTTP polling): Client polls server. Pros - simple, scalable. Cons - higher latency, wasted requests. Use hybrid: push for critical, pull for less urgent.
Bottlenecks and Failure Scenarios
How do you identify bottlenecks in your design?
?
Look at components under high load: Database at X QPS becomes bottleneck (solution: sharding, replicas). Network bandwidth at Y GB/s is saturated (solution: CDN, compression). Single point of failure (solution: redundancy). Cache memory full (solution: eviction policy, more cache nodes).
What failure scenarios should you discuss in Step 4?
?
Database failure (fallback to replicas, automatic failover), Cache failure (circuit breaker to DB, rate limiting), Server failure (load balancer redirects to healthy servers), Network partition (multi-region setup), Third-party service down (timeout, retry with exponential backoff, circuit breaker).
What monitoring metrics should you track?
?
Key metrics: QPS (queries per second), Latency (p50, p95, p99), Error rate (5xx errors), Cache hit rate, Database connection pool utilization, CPU/memory/disk usage. Alerting: When metric exceeds threshold (e.g., QPS > 80% capacity, p99 latency > 1s). Dashboards: Real-time visualization for operations team.
Why should you include cost estimation in Step 4 (Wrap Up)?
?
Shows business awareness (not just technical depth), demonstrates you’ve built real systems (know actual costs), helps justify design decisions (e.g., “CDN costs more but reduces server load”), shows optimization thinking (“Reserved Instances save 40%”). Impresses interviewers by showing maturity and real-world experience!
How do you estimate infrastructure costs for a system?
?
Use formula: Total Cost = Compute + Storage + Network + Cache + Other. Example (URL Shortener): Compute (2 servers × 60), Storage (100 GB × 12), Network/CDN (300 GB × 12), Cache (Redis = 16). Total: ~$125/month. Then mention cost per user or per request to show ROI thinking.
What are typical cloud costs to remember for interviews?
?
Compute: 25/TB/month (S3), 90/TB direct, 100-200/month per 10GB Redis. Small system: 5K-20K/month. Large (10M users): $500K-2M/month.
What cost optimizations should you mention in interviews?
?
Reserved Instances (40-60% discount for 1-3 year commitment), Auto-scaling (scale down off-peak, save 30-50%), CDN for bandwidth (3-5x cheaper than direct), S3 Lifecycle policies (move old data to Glacier, 5x cheaper), Spot Instances (70-90% discount for non-critical), Right-size instances (don’t over-provision), Compress data (reduce bandwidth/storage).
Interview Strategy
How should you respond if you don’t know something in the interview?
?
Never say “I don’t know” and stop! Instead say: “I don’t know this specific technology, but here’s my reasoning…” or “I haven’t worked with X, but based on my understanding of Y, I would approach it like…”. Show your thought process and problem-solving ability.
What should you do if the interviewer gives you a hint?
?
Listen carefully! Hints mean you’re going in the wrong direction. Acknowledge the hint: “That’s a good point, let me reconsider…”. Adapt your design based on the feedback. Being coachable is a key trait interviewers look for. Don’t argue or defend a flawed approach.
How should you handle time pressure in the interview?
?
Use the framework to stay on track. If running low on time: “I’m conscious of time, should I quickly cover the deep dive or focus on wrap-up?”. Don’t spend too long on one area. It’s better to touch all 4 steps at high level than perfect one step and skip others.
What are signs you’re doing well in a system design interview?
?
Interviewer is engaged and asking questions, they’re building on your ideas, they’re asking you to go deeper into specific areas, they mention “that’s interesting” or “good point”, they’re smiling/nodding, the conversation feels collaborative not interrogative.
What are red flags that you’re not doing well?
?
Long awkward silences, interviewer seems disengaged, they’re correcting basic concepts, they keep redirecting you, they’re not asking follow-up questions, you’re doing all the talking without engagement, you spent 20 min on high-level design and haven’t moved on.
Practice Strategy
How should you practice the framework?
?
Week 1: Apply to simple systems (URL shortener, Pastebin, Rate limiter) - focus on following all 4 steps. Week 2: Medium complexity (Twitter, Instagram, Chat) - practice time management. Week 3: Complex systems (YouTube, Uber, Netflix) - practice deep dives. Daily: Pick one system, set 45-min timer, go through all steps, review your process.
What should you focus on when reviewing your practice sessions?
?
Did I follow all 4 steps? Did I ask clarifying questions in Step 1? Did I do back-of-envelope calculations? Did I draw a clear diagram? Did I discuss trade-offs in Step 3? Did I consider failure scenarios in Step 4? What would I do differently? Time management: which step took too long?
Quick Reference
What is the one-sentence summary of each framework step?
?
Step 1: Clarify what you’re building and agree on scope. Step 2: Draw the initial architecture and validate approach. Step 3: Deep dive into 2-3 components with trade-off analysis. Step 4: Discuss bottlenecks, failures, monitoring, and improvements.
What should you absolutely NOT do in a system design interview?
?
Jump straight to design without asking questions, stay silent while designing, over-engineer from the start, ignore the interviewer’s hints, spend 30 minutes on one component, skip back-of-envelope calculations, present only one solution with no alternatives, forget to discuss failure scenarios.
What’s the single most important thing to remember from this chapter?
?
The process matters more than the solution! There’s no one “correct” design. Interviewers assess your problem-solving approach, communication skills, and ability to handle ambiguity. Follow the 4-step framework consistently, think out loud, and discuss trade-offs for every decision.
Total Cards: 39 (added 4 cost estimation cards!)
Review Time: 25-30 minutes
Priority: HIGHEST - Master these before any other chapter
Last Updated: 2026-04-09