System Design
Top 50 System Design Interview Questions (2026) – FAANG-Level Prep Guide
Master 50 most-asked system design questions for FAANG interviews. Covers URL shortener, Twitter, Uber, WhatsApp design with solutions, patterns & tips.
System design interviews feel unpredictable only when you're staring at them as isolated problems. Step back, and a clear pattern emerges — companies keep asking the same architectures over and over, just with different skins on top.
Whether you're prepping for FAANG or a fast-scaling startup, there are roughly 50 canonical system design questions that cover 90% of what you'll ever be asked. This guide groups them into clean categories so you can learn the underlying patterns, not memorize 50 disjointed puzzles.
Bookmark this. If you master these 50, you can walk into almost any system design round with confidence.
How to Approach Any System Design Question
Before diving into the questions, you need a repeatable framework. Most candidates fail not because they can't design systems — but because they don't know how to structure their answers.
Use this 6-step approach for every question:
- Requirements — Clarify functional and non-functional requirements. Ask about scale, latency, consistency needs.
- API Design — Define the core endpoints or interfaces your system exposes.
- Data Model — Sketch the database schema, identify entities and relationships.
- Core Components — Draw the high-level architecture: services, databases, caches, queues.
- Scalability — Address bottlenecks, add load balancers, caching layers, sharding strategies.
- Trade-offs — Discuss CAP theorem implications, consistency vs availability, cost vs performance.
This framework works for every question below. Practice applying it systematically.
Back-of-Envelope Calculations You Must Know
Interviewers expect you to estimate scale. Memorize these numbers:
| Metric | Value | Use Case |
|---|---|---|
| 1 day | 86,400 seconds (~100K) | Daily request calculations |
| 1 month | 2.5 million seconds | Monthly storage estimates |
| 1 character | 1 byte (ASCII) / 2-4 bytes (UTF-8) | Text storage |
| 1 image (compressed) | 200 KB - 1 MB | Image storage |
| 1 video minute (720p) | ~50 MB | Video storage |
| SSD read latency | 100 μs | Storage decisions |
| Network round trip (same datacenter) | 500 μs | Latency budgets |
| Network round trip (cross-continent) | 150 ms | Geo-distribution |
Example calculation for Twitter:
- 500M daily active users, 20% post daily = 100M tweets/day
- 100M tweets / 100K seconds = 1,000 tweets/second (average)
- Peak = 10x average = 10,000 tweets/second
- Storage: 100M tweets × 280 chars × 2 bytes = 56 GB/day of text alone
Practice these calculations until they become second nature.
Master the complete system design roadmap →
The 50 Questions — Organized by Category
We've organized these questions into 8 clusters that map to real architectural patterns. Each cluster links to deeper learning resources on Thita.ai where you can practice with AI-powered coaching.
1. Foundational Design Problems
These are starter questions that test your grasp of core system design building blocks. Expect these at every level — from new grad to senior.
| # | Question | Key Focus |
|---|---|---|
| 1 | Design a URL Shortener | Hashing, collision handling, analytics, read-heavy workloads |
| 2 | Design a Rate Limiter | Token bucket vs sliding window, distributed rate limiting |
| 3 | Design a Distributed Cache | Cache eviction (LRU/LFU), consistency, cache stampede prevention |
| 4 | Design a Key-Value Store | Partitioning, replication, consistency models |
| 5 | Design a Unique ID Generator | Snowflake IDs, UUID trade-offs, clock synchronization |
| 6 | Design a Configuration Management System | Versioning, hot reloading, distributed consistency |
2. Caching & Database Design
These questions probe your understanding of data layer architecture — when to use SQL vs NoSQL, how to shard, and caching strategies.
Deep dive into caching strategies →
Master database replication & sharding →
| # | Question | Key Focus |
|---|---|---|
| 7 | Design a Database Sharding Strategy | Range vs hash vs directory-based sharding, resharding |
| 8 | Design a Read-Heavy System (e.g., Wikipedia) | Read replicas, caching layers, CDN integration |
| 9 | Design a Write-Heavy System (e.g., Logging) | Write-ahead logs, batching, eventual consistency |
| 10 | Design a Multi-Region Database | Conflict resolution, CRDTs, latency optimization |
| 11 | Design a Time-Series Database | Compression, downsampling, retention policies |
| 12 | Design a CDN | Edge caching, cache invalidation, origin shielding |
3. High-Traffic Web Applications
The classics. These are the "Design Twitter" style questions that interviewers love. They test your ability to handle massive scale.
Study real-world case studies →
| # | Question | Key Focus |
|---|---|---|
| 13 | Design Twitter/X | Fan-out-on-write vs fan-out-on-read, timeline caching, celebrity problem |
| 14 | Design Instagram | Feed ranking, image storage, ML integration at scale |
| 15 | Design Facebook News Feed | Edge ranking, real-time updates, personalization |
| 16 | Design YouTube | Video transcoding, chunked delivery, adaptive bitrate streaming |
| 17 | Design Netflix | CDN architecture, regional caches, recommendation engine |
| 18 | Design TikTok | Short-video pipeline, recommendation algorithm, content moderation |
| 19 | Design Reddit | Voting system, comment trees, hot/top/new ranking algorithms |
| 20 | Design LinkedIn | Connection graphs, feed algorithm, people-you-may-know |
4. Messaging & Real-Time Systems
Real-time systems require different thinking — WebSockets, message ordering, presence detection, and delivery guarantees.
| # | Question | Key Focus |
|---|---|---|
| 21 | Design WhatsApp | End-to-end encryption, multi-device sync, message delivery guarantees |
| 22 | Design Slack | WebSockets at scale, channels, presence system, message threading |
| 23 | Design a Chat Application | 1:1 and group chat, read receipts, offline message queue |
| 24 | Design a Notification System | Push, email, SMS channels, priority queues, rate limiting |
| 25 | Design a Live Streaming Platform (Twitch) | RTMP ingestion, HLS delivery, chat integration |
| 26 | Design Zoom/Google Meet | SFU vs MCU architecture, WebRTC, screen sharing |
| 27 | Design an Online Multiplayer Game | Game state synchronization, lag compensation, matchmaking |
5. Search, Feeds & Recommendation Engines
These questions test your understanding of information retrieval, ranking algorithms, and personalization systems.
Explore commonly asked problems →
| # | Question | Key Focus |
|---|---|---|
| 28 | Design Google Search | Web crawling, inverted indexes, PageRank, freshness |
| 29 | Design Search Autocomplete | Trie data structure, ranking by popularity, real-time updates |
| 30 | Design a Recommendation Engine | Collaborative filtering, content-based filtering, hybrid approaches |
| 31 | Design an Ad Delivery System | Real-time bidding, targeting, frequency capping |
| 32 | Design a News Feed Ranking System | ML-based ranking, engagement signals, diversity |
| 33 | Design Spotify's Music Recommendation | Audio fingerprinting, playlist generation, discover weekly |
6. E-commerce & Transactional Systems
These questions focus on consistency, inventory management, payment processing, and handling flash sales.
Learn about consistency models →
| # | Question | Key Focus |
|---|---|---|
| 34 | Design Amazon/E-commerce Platform | Product catalog, cart, checkout flow, order management |
| 35 | Design a Payment Gateway (Stripe) | Idempotency, PCI compliance, retry logic, reconciliation |
| 36 | Design a Ticket Booking System (BookMyShow) | Seat locking, distributed transactions, overbooking prevention |
| 37 | Design Uber/Lyft | Geospatial indexing, driver matching, surge pricing, ETA calculation |
| 38 | Design Airbnb | Search ranking, booking flow, availability calendar, trust system |
| 39 | Design DoorDash/Food Delivery | Order dispatching, delivery time estimation, restaurant integration |
| 40 | Design a Flash Sale System (Shopify) | Queueing, throttling, inventory decrement, fairness |
7. Storage & File Systems
Cloud storage and file synchronization questions test your understanding of distributed file systems, chunking, and deduplication.
| # | Question | Key Focus |
|---|---|---|
| 41 | Design Dropbox/Google Drive | File chunking, sync protocol, conflict resolution, deduplication |
| 42 | Design an Image Hosting Service (Imgur) | Image processing pipeline, CDN delivery, metadata storage |
| 43 | Design S3 (Object Storage) | Eventual consistency, erasure coding, multi-part uploads |
| 44 | Design a Video Transcoding Pipeline | Job queues, worker pools, format optimization |
| 45 | Design Google Docs | Operational transformation (OT), CRDTs, real-time collaboration |
8. Infrastructure, Observability & ML Systems
Senior-level questions often focus on infrastructure components and emerging ML system design.
Learn observability patterns →
Understand scalability patterns →
| # | Question | Key Focus |
|---|---|---|
| 46 | Design a Logging & Monitoring System | Log aggregation (ELK), metrics collection, distributed tracing |
| 47 | Design an Alerting System | Threshold-based vs anomaly detection, alert routing, on-call management |
| 48 | Design a Feature Flag System | Gradual rollouts, A/B testing, kill switches |
| 49 | Design an ML Feature Store | Online vs offline features, feature freshness, versioning |
| 50 | Design an LLM Serving Platform | Request batching, token streaming, model routing, rate limiting |
Quick Reference: Questions by Company
Different companies have favorite questions. Here's a rough mapping based on interview patterns:
| Company | Commonly Asked Questions |
|---|---|
| Design Google Search, YouTube, Google Docs, Distributed Cache | |
| Meta | Design Facebook News Feed, Instagram, WhatsApp, Ad Delivery |
| Amazon | Design E-commerce, Rate Limiter, S3, Notification System |
| Netflix | Design Netflix, CDN, Recommendation Engine, Video Transcoding |
| Uber | Design Uber, Food Delivery, Geospatial Systems, ETA Service |
| Stripe | Design Payment Gateway, Idempotency System, Webhook Delivery |
| Airbnb | Design Airbnb, Search Ranking, Booking System |
Common Mistakes That Kill System Design Interviews
After coaching hundreds of engineers, we see the same mistakes repeatedly. Avoid these:
1. Jumping Straight to the Solution
The mistake: Starting to draw boxes before clarifying requirements. Why it fails: You might design a system for 1,000 users when they wanted 1 billion. Or optimize for consistency when they needed availability. The fix: Spend the first 5 minutes asking clarifying questions. "What's the expected scale? Read-heavy or write-heavy? What's the latency requirement?"
2. Not Discussing Trade-offs
The mistake: Presenting one solution as if it's the only option. Why it fails: Interviewers want to see your decision-making process, not just a final answer. Every design choice has trade-offs. The fix: For every major decision, say: "We could do X or Y. X is better for [reason], but Y would be better if [condition]. Given our requirements, I'll go with X."
3. Ignoring Failure Scenarios
The mistake: Designing only for the happy path. Why it fails: Real systems fail. Interviewers want to know you've thought about what happens when a database goes down, a network partitions, or traffic spikes 100x. The fix: Proactively mention: "What happens if this service fails? We'd need circuit breakers, retries with exponential backoff, and a fallback strategy."
4. Over-Engineering from the Start
The mistake: Adding Kafka, Redis, Elasticsearch, and Kubernetes before establishing the basic design. Why it fails: It shows you don't understand when complexity is justified. Simple solutions often work until proven otherwise. The fix: Start simple. "Let's start with a single server and database. Now, as we scale to 10K requests/second, here's where we'd need to add caching..."
5. Poor Time Management
The mistake: Spending 30 minutes on the database schema, leaving 5 minutes for everything else. Why it fails: You never get to discuss the interesting parts — scaling, trade-offs, failure handling. The fix: Allocate time: 5 min requirements, 5 min high-level design, 15 min component deep-dive, 10 min scaling/trade-offs, 5 min questions.
6. Not Drawing Diagrams
The mistake: Explaining everything verbally without visual aids. Why it fails: It's hard to follow, and you'll forget components. Diagrams help you think and help the interviewer follow along. The fix: Draw as you talk. Boxes for services, cylinders for databases, arrows for data flow. Label everything.
5 Questions Deep-Dived
Let's walk through the key design decisions for five popular questions:
Design a URL Shortener
Core challenge: Generate short, unique keys that map to long URLs with minimal collisions.
Key decisions:
- Encoding: Base62 (a-z, A-Z, 0-9) gives 62^7 = 3.5 trillion combinations for 7-character keys
- ID Generation: Counter-based (simple but predictable) vs hash-based (random but collision-prone)
- Storage: Key-value store (Redis for hot data, DynamoDB/Cassandra for persistence)
- Read optimization: Cache popular URLs, 301 vs 302 redirects
- Analytics: Async event logging, time-series storage for click tracking
Practice URL Shortener design →
Design Twitter
Core challenge: Deliver personalized timelines to 500M+ users with sub-second latency.
Key decisions:
- Fan-out strategy: Fan-out-on-write for normal users (pre-compute timelines), fan-out-on-read for celebrities (merge at read time)
- Timeline storage: Redis sorted sets for home timelines
- Tweet storage: Sharded MySQL/PostgreSQL by user ID
- The celebrity problem: Hybrid approach — don't fan out tweets from users with 1M+ followers
- Caching layers: Tweet cache, user cache, timeline cache
Study the Twitter case study →
Design a Rate Limiter
Core challenge: Protect APIs from abuse while being fair to legitimate users.
Key decisions:
- Algorithm choice: Token bucket (bursty traffic OK), sliding window (smoother limits), leaky bucket (constant rate)
- Distributed rate limiting: Redis with Lua scripts for atomic operations
- Granularity: Per-user, per-IP, per-API-key, per-endpoint
- Response handling: 429 Too Many Requests with Retry-After header
- Edge cases: Clock drift in distributed systems, race conditions
Practice Rate Limiter design →
Design WhatsApp
Core challenge: Deliver billions of messages daily with end-to-end encryption and guaranteed delivery across unreliable mobile networks.
Key decisions:
- Connection management: Long-lived TCP connections (or WebSockets) with heartbeats. Each user maintains one persistent connection.
- Message delivery: Store-and-forward model. Messages stored on server until recipient acknowledges receipt. Retry with exponential backoff.
- Encryption: End-to-end encryption using Signal Protocol. Server never sees plaintext — only encrypted blobs.
- Multi-device sync: Message keys shared across devices. Each device gets its own encrypted copy.
- Group messaging: Fan-out at the sender's device. One encrypted message per recipient (not broadcast).
- Presence/typing indicators: Ephemeral UDP packets for real-time presence. No persistence needed.
- Media handling: Upload to blob storage (S3), share encrypted link. Receiver downloads and decrypts locally.
Scale insight: WhatsApp famously served 900M users with only 50 engineers. Key: Erlang for massive concurrency, extreme focus on simplicity.
Design Uber/Lyft
Core challenge: Match drivers and riders in real-time across millions of concurrent requests with sub-second location updates.
Key decisions:
- Geospatial indexing: Divide the world into cells (S2 cells, H3, or geohash). Store driver locations in cells. Query neighboring cells for nearby drivers.
- Location updates: Drivers send location every 4 seconds. Write-heavy workload — use Redis or in-memory stores, not traditional DBs.
- Matching algorithm: Not just "nearest driver." Consider: driver's direction, ETA, driver rating, rider preferences, surge area boundaries.
- ETA calculation: Pre-computed road network graphs. Dijkstra's or A* for routing. Account for real-time traffic from driver GPS data.
- Surge pricing: Monitor supply/demand per cell. When demand > supply × threshold, increase prices. Eventually consistent across cells.
- Dispatch service: Stateless microservice. Query nearby drivers, rank by score, send ride request. If declined/timeout, try next driver.
- Ride lifecycle: State machine: Requested → Matched → Driver En Route → Trip Started → Trip Completed → Payment Processed.
Failure handling: What if the dispatch service crashes mid-match? Use idempotency keys. Store ride state in persistent DB. Retry-safe operations.
How to Practice System Design with AI
Reading about system design is step one. Actually practicing — explaining your design out loud, drawing diagrams, handling follow-up questions — is where real learning happens.
Thita.ai's AI-Powered System Design Practice
1. AI Mock Interviews Practice any of these 50 questions with an AI interviewer that asks realistic follow-up questions. Get instant feedback on your communication, technical depth, and trade-off analysis.
Start a system design mock interview →
2. AI Coach for Concepts Stuck on a concept? Ask the AI coach to explain sharding strategies, CAP theorem trade-offs, or any topic. It draws diagrams and walks you through examples.
3. Structured Learning Path Follow the HLD Learning Path covering all 14 system design categories with 120+ topics — from service architectures to real-world case studies.
Suggested Study Order by Experience Level
Not all 50 questions are equal. Here's how to prioritize based on where you are:
If You're a Beginner (0-2 years experience)
Start here (Week 1-2):
- Design a URL Shortener — Learn basic API design, hashing, database choices
- Design a Rate Limiter — Understand algorithms, distributed systems basics
- Design a Key-Value Store — Learn partitioning and replication fundamentals
Then move to (Week 3-4): 4. Design a Distributed Cache — Caching strategies, eviction policies 5. Design a Notification System — Message queues, different delivery channels 6. Design a Chat Application — Real-time communication basics
Concepts to master first: Client-server architecture, SQL vs NoSQL, caching basics, REST APIs, basic scalability (vertical vs horizontal).
If You're Intermediate (2-5 years experience)
Focus on these classics (Week 1-2):
- Design Twitter — Fan-out strategies, timeline caching
- Design Instagram — Media storage, feed ranking
- Design WhatsApp — Real-time messaging, delivery guarantees
Add complexity (Week 3-4): 4. Design Uber — Geospatial indexing, real-time matching 5. Design Netflix — CDN, video streaming, recommendations 6. Design a Payment Gateway — Transactions, idempotency, consistency
Concepts to master: Sharding strategies, CAP theorem, message queues (Kafka), caching layers, microservices patterns.
Study real-world architectures →
If You're Senior (5+ years experience)
Focus on depth and trade-offs:
- Design Google Search — Large-scale distributed systems
- Design an Ad Delivery System — Real-time bidding, ML integration
- Design a Distributed Database — Consensus, replication, partitioning
- Design an ML Feature Store — Online/offline serving, feature freshness
- Design an LLM Serving Platform — Batching, streaming, model routing
What interviewers expect at your level:
- Lead the conversation, don't wait for prompts
- Proactively discuss failure modes and mitigation
- Make quantified trade-off decisions ("This adds 50ms latency but improves reliability from 99.9% to 99.99%")
- Discuss operational concerns: monitoring, debugging, deployment
Frequently Asked Questions
How should beginners prepare for system design interviews?
Start with foundational questions (URL Shortener, Rate Limiter, Key-Value Store). Master the 6-step framework: Requirements → API → Data Model → Components → Scalability → Trade-offs. Read "Designing Data-Intensive Applications" by Martin Kleppmann. Practice explaining designs out loud — system design is as much about communication as technical knowledge.
How many questions should I practice before interviews?
Aim for 15-20 questions across different categories. It's better to deeply understand 15 questions than superficially memorize 50. Focus on learning the underlying patterns — once you understand sharding, caching, and message queues, you can apply them to any new question.
What system design questions are most common at Meta?
Meta frequently asks: Design Facebook News Feed, Design Instagram, Design WhatsApp, Design Messenger, and Design the Ad Delivery System. They focus heavily on scale (billions of users) and real-time systems. Brush up on fan-out strategies, ranking algorithms, and message delivery guarantees.
What's the best structure to answer system design interviews?
Use the RESHADED framework or similar:
- Requirements clarification
- Estimation (back-of-envelope calculations)
- Storage schema design
- High-level design
- API design
- Detailed component design
- Error handling and edge cases
- Discuss trade-offs and alternatives
How long does system design preparation take?
For someone with 2+ years of experience: 4-8 weeks of focused prep (1-2 hours daily). Complete beginners may need 3-4 months. The key is consistent practice — design one system per day, explain it out loud, and get feedback.
Should I draw diagrams during system design interviews?
Yes, always. Diagrams help you organize your thoughts and help the interviewer follow along. Practice drawing clean architecture diagrams with boxes for services, cylinders for databases, and arrows for data flow. Tools like Thita.ai's AI Interview let you practice with a visual canvas.
What if I get stuck during a system design interview?
Don't panic — think out loud. Say: "I'm not sure about the best approach here. Let me think through the options..." Then verbalize your thought process. Interviewers appreciate seeing how you reason through problems. If truly stuck, ask a clarifying question: "Would it help to first establish the scale we're targeting?" This buys you time and shows maturity.
How do I handle deep follow-up questions I don't know the answer to?
Be honest, then reason from first principles. Say: "I haven't worked with that specific technology, but based on what I know about similar systems..." Then apply general principles. For example, if asked about a specific database you don't know: "I'm not familiar with CockroachDB specifically, but as a distributed SQL database, it likely uses Raft for consensus and sharding for horizontal scale. Is that the direction you'd like me to explore?"
What's the difference between system design interviews at startups vs FAANG?
Scale and depth expectations differ significantly:
- FAANG: Expects you to design for billions of users. Deep knowledge of distributed systems. Will probe trade-offs extensively. 45-60 minute rounds.
- Startups: More practical focus. "How would you build this with 2 engineers and ship in 3 months?" Values pragmatic decisions over theoretical perfection. Often shorter rounds (30-45 min).
Adjust your approach: At FAANG, proactively discuss sharding and geo-distribution. At startups, emphasize simplicity and iteration speed.
How important is knowledge of specific technologies (Kafka, Redis, etc.)?
Concepts matter more than specific tools, but knowing tools helps. You don't need to know every configuration option of Kafka, but you should understand when to use a message queue vs a database, and why Kafka's log-based model differs from traditional queues. If you mention a technology, be prepared to explain why you chose it over alternatives.
Ready to Master System Design?
These 50 questions represent the core of what you need to know. But knowing the questions isn't enough — you need to practice articulating your designs, handling follow-up questions, and making trade-off decisions under pressure.
Your next steps:
- Pick 3 questions from different categories and practice explaining them out loud
- Take an AI mock interview to get real-time feedback: Start here →
- Follow the structured learning path to build deep understanding: HLD Learning Path →
- Read case studies of how real companies built these systems: Real-World Case Studies →
3 free AI mock interviews per month. No credit card required.
Related Articles
- The Ultimate System Design Roadmap: 120 Topics to Master — Complete learning path for system design
- The 90 DSA Patterns That Cover 99% of Coding Interviews — Master algorithms alongside system design
- AI Interview Practice: Free Mock Interview Simulator — How to use AI for interview prep
- Best AI Interview Prep Tools 2026 — Compare top platforms
External Resources
- Thita.ai HLD Learning Path — 120 topics across 14 categories
- Thita.ai AI Coach — Get explanations for any concept
- Thita.ai AI Mock Interviews — Practice with real-time feedback
Have questions or want to discuss system design strategies? Join our Discord community and connect with thousands of engineers preparing for interviews.
Last Updated: September 2026 | Reading Time: 18 minutes