System Design Interview Guide: Framework, Questions, and Practice Strategy

The system design interview is the highest-leverage round in any senior engineering interview loop. Unlike coding rounds, there is no single correct answer — interviewers evaluate how you think through ambiguity, make trade-offs, and communicate architectural decisions under pressure.

This guide covers the complete framework used by candidates who pass system design interviews at FAANG and top-tier companies.

The System Design Interview Framework#

Every system design question can be approached with the same six-step structure. Interviewers expect you to drive the conversation through these phases.

1. Requirements Clarification (3–5 minutes)#

Before drawing a single box, ask questions. Distinguish between functional and non-functional requirements.

• Functional: What does the system do? Who are the users? What are the core features?
• Non-functional: What scale are we targeting? What latency is acceptable? Do we need strong consistency or is eventual consistency fine?

For example, if asked to design Twitter, clarify: Are we building the tweet posting flow, the home feed, search, or all three? Should we handle media uploads? What about DMs?

2. Back-of-the-Envelope Estimation (3–5 minutes)#

Estimation grounds your design in reality. Interviewers want to see that you can reason about scale.

Key metrics to estimate:

• QPS (Queries Per Second): If you have 100M daily active users and each makes 10 requests per day, that is roughly 100M × 10 / 86,400 ≈ 12,000 QPS. Peak traffic is typically 2–3x average.
• Storage: If each record is 1 KB and you store 500M records per year, that is 500 GB/year. Over five years, 2.5 TB.
• Bandwidth: QPS × average response size. 12,000 QPS × 10 KB = 120 MB/s.

These numbers inform whether you need sharding, caching, CDNs, or message queues.

3. API Design (3–5 minutes)#

Define the contract between client and server. Use REST or gRPC style.

POST /api/v1/tweets
  body: { user_id, content, media_ids[] }
  response: { tweet_id, created_at }

GET /api/v1/feed?user_id={id}&cursor={cursor}&limit=20
  response: { tweets[], next_cursor }

This step forces you to think about the data model early and signals that you build systems from the user's perspective.

4. High-Level Design (10–15 minutes)#

Draw the major components and how they interact. A typical architecture includes:

• Client → Load Balancer → Application Servers → Database
• Add Cache (Redis/Memcached) for read-heavy paths
• Add Message Queue (Kafka/SQS) for async processing
• Add CDN for static assets and media
• Add Object Storage (S3) for files

Keep it simple first. You will add complexity in the deep dive.

5. Deep Dive (10–15 minutes)#

The interviewer will pick one or two components to explore. Be ready to go deep on:

• Database choice: SQL vs. NoSQL. When would you pick Cassandra over PostgreSQL?
• Sharding strategy: Hash-based vs. range-based. How do you handle hot partitions?
• Caching strategy: Cache-aside, write-through, write-behind. Cache invalidation approaches.
• Consistency model: Strong vs. eventual. How does this affect the user experience?

6. Bottlenecks and Improvements (3–5 minutes)#

Proactively identify what can fail and how to mitigate it:

• Single points of failure → add redundancy
• Hot spots → consistent hashing, rate limiting
• Data loss → replication, backups
• Slow reads → caching, denormalization, read replicas

Common System Design Interview Questions#

URL Shortener (TinyURL)#

Core challenge: Generate unique short codes and redirect efficiently.

• Use a key generation service or base62 encoding of an auto-increment ID
• Store mappings in a key-value store (DynamoDB, Redis)
• Cache popular URLs; use 301 vs. 302 redirects based on analytics needs
• Estimation: 100M URLs created per month, 10:1 read-to-write ratio → 100B redirects/month ≈ 38,000 read QPS

Twitter / Social Media Feed#

Core challenge: Fan-out problem — how do you deliver tweets to millions of followers?

• Fan-out on write: When a user tweets, push to all followers' feeds (fast reads, expensive writes)
• Fan-out on read: Build the feed at read time by pulling from followed users (cheap writes, slow reads)
• Hybrid: Fan-out on write for normal users, fan-out on read for celebrities (the actual Twitter approach)

Chat System (WhatsApp / Slack)#

Core challenge: Real-time delivery with ordering guarantees.

• Use WebSockets for persistent connections
• Message queue per conversation for ordering
• Store messages in a time-series optimized database
• Handle offline users with push notifications and message sync on reconnect

Video Streaming (Netflix)#

Core challenge: Serve large files at scale with low latency.

• Transcode videos into multiple resolutions and codecs (adaptive bitrate streaming)
• Distribute via CDN with edge caching
• Use a recommendation engine backed by ML pipelines
• Separate the control plane (metadata, auth) from the data plane (video delivery)

Ride-Sharing (Uber)#

Core challenge: Real-time location matching at scale.

• Use a geospatial index (QuadTree, GeoHash) to find nearby drivers
• Match riders to drivers using a dispatch service
• Track locations via WebSocket or frequent polling
• Handle surge pricing with a pricing service that monitors supply/demand ratios

Trade-Offs Interviewers Want to Hear#

Strong candidates frame decisions as trade-offs, not absolutes:

What Interviewers Actually Look For#

1. Structured thinking: Can you break an ambiguous problem into manageable pieces?
2. Communication: Do you explain your reasoning clearly and check in with the interviewer?
3. Breadth: Do you understand the major building blocks (databases, caches, queues, load balancers)?
4. Depth: Can you go deep on at least one area when pushed?
5. Trade-off awareness: Do you acknowledge alternatives and explain why you chose one path?
6. Practical sense: Are your estimates reasonable? Does the design actually work at the stated scale?

Mistakes to Avoid#

• Jumping to the solution: Skipping requirements and estimation makes your design look arbitrary.
• Over-engineering: Do not add Kafka, Kubernetes, and a microservices mesh for a system that handles 100 QPS.
• Ignoring the interviewer: They drop hints. If they ask about a specific component, pivot to it.
• Not quantifying: Saying "we need a cache" without explaining why (e.g., 90% read traffic, 50ms latency requirement) is weak.
• Single database syndrome: Assuming one PostgreSQL instance handles everything at any scale.
• Memorizing solutions: Interviewers can tell. Understand the principles so you can adapt to novel questions.

Practice Strategy#

1. Learn the building blocks: Understand how each component works (load balancers, consistent hashing, replication, sharding, CDNs, message queues).
2. Practice the framework: Run through 2–3 problems per week using the six-step structure above.
3. Time yourself: Aim to complete a full design in 35–40 minutes.
4. Explain out loud: Practice talking through your design as if the interviewer is in the room.
5. Study real architectures: Read engineering blogs from companies that operate at scale. Understand why they made their choices.
6. Get feedback: Practice with peers or use tools that let you iterate on designs quickly.

Start Practicing Today#

The system design interview rewards structured thinking and broad systems knowledge. The framework above gives you the structure. The rest comes from practice.

Practice system design at codelit.io — generate architectures for any system in seconds.

---

140 articles on system design at codelit.io/blog.