Top 25 System Design Interview Questions (2026)

You're 45 minutes into a system design interview. The interviewer asks you to design Instagram. Your mind goes blank. Where do you even start?

This happens to engineers every day. Not because they lack skill, but because they've never seen the patterns that connect all system design questions.

After conducting 200+ system design interviews at top tech companies, I've identified the 25 questions that appear in 90% of interviews. More importantly, I'll show you the underlying patterns that let you tackle any question confidently.

---

Why System Design Interviews Exist

System design interviews aren't trivia tests. Companies use them to answer one question:

"Can this person build and scale real systems?"

They're evaluating:

• Problem decomposition , Can you break ambiguous problems into concrete components?
• Technical depth , Do you understand how databases, caches, and queues actually work?
• Trade-off analysis , Can you articulate why you'd choose Cassandra over PostgreSQL?
• Communication , Can you explain complex systems clearly to teammates?

The good news? These skills are learnable. And the questions are predictable.

---

The 25 Most Common System Design Questions

I've organized these by category. Each category shares common patterns, learn the pattern, and you can handle variations.

URL Shorteners & Key-Value Systems

1. Design a URL Shortener (TinyURL/Bitly)

The classic starter question. Tests your understanding of:

• Hash generation and collision handling
• Database schema design
• Read-heavy optimization with caching
• Analytics and click tracking at scale

Key insight: This is fundamentally a key-value lookup problem. The short URL is the key; the long URL is the value.

2. Design a Paste Service (Pastebin)

Similar to URL shortener, but with larger payloads. Adds complexity around:

• Object storage for content
• Expiration and cleanup
• Syntax highlighting (compute at write vs. read)

3. Design a Key-Value Store

Goes deeper into storage engine design:

• LSM trees vs. B-trees
• Compaction strategies
• Replication and consistency models

---

Social & Feed Systems

4. Design Twitter/X

Tests real-time systems and fan-out strategies:

• Tweet storage and retrieval
• Timeline generation (push vs. pull vs. hybrid)
• Handling celebrity accounts with millions of followers

Key insight: The core challenge is fan-out. When someone with 10M followers tweets, do you write to 10M timelines (push) or compute on read (pull)?

5. Design Instagram

Focuses on media-heavy systems:

• Image upload, processing, and CDN distribution
• Feed ranking algorithms
• Stories (ephemeral content with TTL)

6. Design Facebook News Feed

The most complex feed system:

• Multi-signal ranking (friends, pages, groups, ads)
• Real-time updates vs. eventual consistency
• Aggregation (grouping similar stories)

7. Design LinkedIn

Adds professional graph complexity:

• Connection degrees (1st, 2nd, 3rd)
• Job recommendations
• Company pages and followers

---

Messaging & Real-Time Communication

8. Design WhatsApp/Messenger

Tests real-time infrastructure:

• WebSocket connection management
• Message delivery guarantees (at-least-once, exactly-once)
• End-to-end encryption key exchange
• Offline message queuing

Key insight: The hard part isn't sending messages, it's guaranteeing delivery and ordering across unreliable networks.

9. Design Slack

Adds workspace and channel complexity:

• Channel-based message routing
• Search across message history
• File sharing and storage
• Presence indicators (online/away/offline)

10. Design a Notification System

Cross-cutting concern for most applications:

• Multi-channel delivery (push, email, SMS, in-app)
• User preference management
• Rate limiting and batching
• Delivery tracking and retry logic

---

Storage & File Systems

11. Design Dropbox/Google Drive

Tests distributed file storage:

• Chunking large files
• Deduplication across users
• Sync conflict resolution
• Delta sync (only upload changed bytes)

Key insight: Never store the same file twice. Content-addressable storage (hash as key) enables massive deduplication.

12. Design Google Docs

Real-time collaboration is the challenge:

• Operational Transformation (OT) or CRDTs
• Cursor position synchronization
• Version history and branching
• Permission management

13. Design YouTube/Netflix

Video at scale:

• Transcoding pipeline (multiple resolutions, codecs)
• Adaptive bitrate streaming
• CDN architecture and edge caching
• Recommendation engine

---

Search & Discovery

14. Design Google Search

The ultimate scale problem:

• Web crawling and indexing
• Inverted index data structures
• PageRank and ranking signals
• Query parsing and intent detection

15. Design Typeahead/Autocomplete

Latency-critical system:

• Trie data structures
• Prefix matching at scale
• Personalization and trending queries
• Caching strategies for hot queries

16. Design a Web Crawler

Distributed systems fundamentals:

• URL frontier management
• Politeness (respecting robots.txt, rate limits)
• Duplicate detection
• Incremental crawling

---

E-Commerce & Transactions

17. Design Amazon/E-Commerce Platform

Tests transactional systems:

• Product catalog and inventory management
• Shopping cart (session vs. persistent)
• Order processing pipeline
• Payment integration

Key insight: The inventory problem is deceptively hard. How do you prevent overselling when 1000 people click "Buy" on the last item simultaneously?

18. Design an Online Booking System (Hotels/Flights)

Adds time-based inventory:

• Availability calendar management
• Double-booking prevention
• Cancellation and refund handling
• Dynamic pricing

19. Design Uber/Lyft

Location-based matching:

• Geospatial indexing (QuadTrees, Geohash)
• Real-time driver location updates
• Matching algorithm (nearest vs. optimal)
• Surge pricing calculation
• ETA prediction

---

Infrastructure & Platform

20. Design a Rate Limiter

Fundamental building block:

• Token bucket vs. sliding window algorithms
• Distributed rate limiting with Redis
• Per-user, per-IP, per-API limits
• Graceful degradation

21. Design a Distributed Cache

Caching is everywhere:

• Cache eviction policies (LRU, LFU)
• Consistent hashing for distribution
• Cache invalidation strategies
• Thundering herd prevention

22. Design a Message Queue (Kafka)

Async processing backbone:

• Partitioning and ordering guarantees
• Consumer groups and offset management
• Exactly-once delivery semantics
• Retention and replay

23. Design a Distributed Task Scheduler

Background job processing:

• Job priority and scheduling
• Worker pool management
• Failure handling and retries
• Idempotency

---

Metrics & Monitoring

24. Design a Metrics/Analytics System

Time-series at scale:

• High-cardinality data handling
• Rollups and downsampling
• Query patterns (last hour vs. last year)
• Alerting and anomaly detection

25. Design a Logging System (Splunk/ELK)

Observability infrastructure:

• Log ingestion at massive scale
• Full-text search indexing
• Log retention and archival
• Correlation across services

---

The 5 Patterns Behind Every Question

Here's what took me years to realize: every system design question is a combination of 5 core patterns.

Pattern 1: Read-Heavy vs. Write-Heavy

First, identify the read/write ratio:

Pattern 2: Real-Time vs. Batch

Does the user need data immediately or eventually?

• Real-time: WebSockets, streaming, in-memory processing
• Near real-time: Message queues, eventual consistency
• Batch: Scheduled jobs, data warehouses

Pattern 3: Strong vs. Eventual Consistency

What happens if users see stale data?

• Banking: Strong consistency required (double-spend = disaster)
• Social feeds: Eventual consistency acceptable (missing a tweet for 30s is fine)
• Inventory: Depends on business model (overselling tolerance)

Pattern 4: Stateless vs. Stateful

Can you restart the server without losing user context?

• Stateless: Easier to scale, use external stores for state
• Stateful: WebSocket connections, game servers, require sticky sessions

Pattern 5: Push vs. Pull

How does data flow to users?

• Push (fan-out on write): Pre-compute and store for each user
• Pull (fan-out on read): Compute on demand when user requests
• Hybrid: Push for active users, pull for inactive

---

What Interviewers Actually Evaluate

After giving 200+ interviews, here's my rubric:

Requirement Gathering (10%)

Did you ask clarifying questions before designing?

Good: "What's our expected QPS? Are we optimizing for latency or throughput?"

Bad: Immediately jumping to "We'll use Kafka and Redis..."

High-Level Design (25%)

Can you sketch the major components and their interactions?

Good: Clear boxes, labeled arrows, explained data flow

Bad: A mess of components with no clear request path

Deep Dive (35%)

Can you go deep on 2-3 components when pushed?

Good: "For the database, I'd use PostgreSQL with read replicas. Here's the schema... and here's why I chose this index..."

Bad: "We'll use a database" (and can't elaborate)

Trade-off Discussion (20%)

Do you acknowledge alternatives and explain your choices?

Good: "We could use Cassandra for better write throughput, but PostgreSQL gives us ACID guarantees we need for payments."

Bad: Presenting your design as the only option

Communication (10%)

Can you explain clearly without jargon?

Good: Checking in with interviewer, drawing diagrams, structured explanation

Bad: 20-minute monologue with no interaction

---

How to Prepare: A 4-Week Plan

Week 1: Fundamentals

• Learn the building blocks: databases, caches, queues, load balancers
• Understand CAP theorem and consistency models
• Study consistent hashing and partitioning

Week 2: Core Questions

• Design URL Shortener
• Design Twitter
• Design WhatsApp
• Design Rate Limiter

Week 3: Advanced Questions

• Design Uber
• Design YouTube
• Design Dropbox
• Design Typeahead

Week 4: Mock Interviews

• Practice with peers or use mock interview platforms
• Time yourself (45 minutes per question)
• Get feedback on communication, not just technical correctness

---

Common Mistakes to Avoid

1. Not clarifying requirements

Don't assume. A "messaging app" could mean SMS gateway or real-time chat, completely different architectures.

2. Jumping to solutions

"Let's use Kafka!" Why? What problem does it solve here?

3. Ignoring scale

A system for 100 users is different from one for 100 million. Always establish scale early.

4. Over-engineering

You don't need microservices, Kubernetes, and event sourcing for a URL shortener. Match complexity to requirements.

5. Single points of failure

If one server dies, does your system die? Always address redundancy.

6. Ignoring the interviewer

System design is collaborative. Check in, ask if they want you to go deeper, respond to hints.

---

Your Next Step

System design interviews are predictable. The same 25 questions, with variations, appear in 90% of interviews.

Master these questions. Understand the underlying patterns. Practice explaining your thinking clearly.

The engineers who pass system design interviews aren't necessarily smarter. They're just better prepared.---

Frequently Asked Questions

How long should I prepare for system design interviews?

Most engineers need 4-8 weeks of focused preparation. If you have production experience with distributed systems, you might need less. If this is new territory, budget more time.

Should I memorize solutions to these questions?

No. Memorized answers fail in two ways: (1) interviewers can tell, and (2) they ask follow-up questions your memorized answer can't handle. Instead, understand the patterns so you can reason through any variation.

What if I don't have distributed systems experience?

You can still pass. Focus on understanding the fundamentals (databases, caching, queuing) and practice applying them. Many successful candidates learn system design specifically for interviews.

How do I practice without a study partner?

Talk out loud while designing. Explain your thinking as if someone were listening. Record yourself and review. This builds the communication muscle that interviews require.

What resources should I use?

Start with the fundamentals (how databases and caches work), then practice with real questions. Avoid resources that only give you solutions without explaining the reasoning.