Complete System Design Interview Guide 2026: From Fundamentals to Real-World Architectures

The system design interview is where engineering judgment matters more than coding ability. Unlike a coding interview (which tests whether you can write correct code), a system design interview tests whether you can architect a solution to a problem that doesn't have a single right answer — and defend your choices under pressure.

This guide covers everything: the framework, the fundamentals, the most commonly asked systems, and how to prepare when you have four weeks.

If you're targeting a specific company, jump to your target:

• Google System Design — Googleyness + architectural depth
• Meta System Design — Product sense + scalability
• Amazon System Design — Leadership Principles + bias for action
• Netflix System Design — Stream reliability + content delivery

What Is a System Design Interview?

A system design interview (SDI) asks you to architect a real-world system under time pressure — typically 45 minutes for a large-scale system like "Design Twitter" or "Design a video streaming service."

You're not building the system. You're making the key architectural decisions: what components, how they connect, where the bottlenecks are, and how you'd scale from 1,000 to 100 million users.

The premise: Great engineers don't just write code — they make good architectural decisions under constraints. The SDI is a proxy for the decisions you'd make on the job.

What Interviewers Actually Evaluate

| Skill | What They Look For |

|-------|-------------------|

| Communication | Can you talk through your thinking out loud? Do you ask clarifying questions or jump to solutions? |

| Problem scoping | Do you understand what's being asked? Do you identify constraints before designing? |

| Architecture knowledge | Do you know the building blocks (databases, caches, queues, CDNs)? |

| Trade-off thinking | Do you explain why you chose X over Y? Can you acknowledge the downsides? |

| Scalability reasoning | Can you identify bottlenecks and propose scaling strategies? |

| Leadership Principles | (Amazon) Do your decisions reflect ownership, bias for action, and customer obsession? |

The System Design Framework

Every SDI follows the same structure. Internalize this framework before your interview — it's your scaffolding for any problem.

Step 1: Clarify Requirements (5 min)

Before you design anything, ask:

Functional requirements:

• What does the system do? (e.g., "users can post tweets and follow other users")
• Who are the primary users? (e.g., "active users posting once/day, passive users reading 10x more")
• What's the read/write ratio? (e.g., "100:1 reads to writes for Twitter")

Non-functional requirements:

• How many users? (1K → 100K → 10M → 100M+)
• What latency is acceptable? (e.g., "feed load <200ms")
• What's the availability target? (e.g., "99.9% uptime = ~8 hours downtime/year")
• Any geographic constraints? (global vs. single-region)

Never skip this step. Interviewers will interrupt if you start designing before clarifying. Better to ask now than realize mid-design that you've optimized for the wrong thing.

Step 2: High-Level Architecture (10 min)

Draw the major components:

Users → API Layer → Services → Data Layer
                  ↳ Cache
                  ↳ Queue
                  ↳ Search

Key questions to answer:

• What's the client? (mobile app, web, or both)
• How do users reach the system? (CDN, load balancer)
• Where does data live? (databases, object storage)
• What happens in the middle? (microservices, queues, cache)

Don't go deep yet. You're painting the map. You'll fill in the details in step 3.

Step 3: Data Storage Decisions (10 min)

This is where most SDIs focus — which database, which cache, which storage system.

Common decisions:

| Decision | Options | When to Choose |

|----------|---------|---------------|

| Primary database | SQL (PostgreSQL) vs. NoSQL (Cassandra, DynamoDB) | SQL for relational data; NoSQL for write-heavy, schema-flexible |

| Caching | Redis, Memcached | When read-heavy (>90%) and data is relatively static |

| File storage | S3, GCS | For images, videos, user-generated content |

| Search | Elasticsearch, Solr | When you need full-text search or complex queries |

| Messaging/Queue | Kafka, RabbitMQ, SQS | When you need async processing or event-driven architecture |

Trade-off thinking is critical here. Every choice has a downside. Acknowledge it.

Step 4: Scale and Bottlenecks (10 min)

Take your design and stress it:

Scale up:

• "What happens when we go from 1,000 to 1,000,000 users?"
• "Where does this design break?"

Common bottlenecks:

1. Database saturation — Too many reads/writes on a single DB
2. Single point of failure — No replication or redundancy
3. Cache stampede — All requests hitting cache at once after expiry
4. Hot partitions — One shard receiving more load than others

Scaling strategies:

• Horizontal scaling — Add more machines instead of bigger ones
• Read replicas — Route reads to copies, writes to primary
• Sharding — Partition data across multiple databases
• Cache warming — Prepopulate cache to avoid stampede
• Rate limiting — Prevent abuse that overwhelms the system

Step 5: Trade-offs and Edge Cases (5 min)

End with honesty:

What did you sacrifice?

• "I chose eventual consistency over strong consistency for reads. This means users might briefly see stale data."
• "I used a cache, which means I need to handle cache invalidation. That's an operational complexity."

What would you do next?

• "If I had more time, I'd add monitoring and alerting."
• "The first thing I'd instrument is cache hit rate and DB query latency."

Fundamental Concepts

CAP Theorem

Every distributed system must choose 2 of 3:

| Property | Description | Examples |

|----------|-------------|----------|

| Consistency | All reads see the same data | Traditional databases |

| Availability | Every request gets a response | Caches, Cassandra (writes) |

| Partition tolerance | System works even if network fails | Almost all real systems |

Practical note: In practice, network partitions happen. You choose between "be consistent during partition" (CP) or "stay available during partition" (AP). Most systems choose AP for user-facing services (availability wins) and CP for financial systems (consistency wins).

SQL vs. NoSQL

| Criteria | SQL | NoSQL |

|----------|-----|-------|

| Schema | Fixed | Flexible |

| Transactions | ACID | Eventually consistent (usually) |

| Scaling | Vertical | Horizontal |

| Queries | Complex JOINs | Simple key-value or scan |

| Use when | Data is relational, need transactions | Write-heavy, schema changes, massive scale |

Twitter example: User data (follows, tweets) is highly relational — SQL works. Tweet content storage for search — NoSQL key-value works better.

Load Balancing Strategies

| Strategy | How It Works | Best For |

|----------|-------------|----------|

| Round Robin | Each server gets requests in rotation | Simple, equal traffic |

| Least Connections | Route to server with fewest active | Variable request duration |

| IP Hash | Hash client IP to same server | Session affinity |

| Weighted | Configure traffic % per server | Different server capacities |

Caching Patterns

Cache-aside (most common):

Read: App → Cache (miss) → DB → Cache (store) → App
Write: App → DB → Cache (invalidate)

Write-through:

Write: App → Cache → DB (both must succeed)

Read-through:

Read: App → Cache (miss) → DB → Cache → App

Cache invalidation: The hard problem. When does the cache get updated? Options: TTL (time-based expiry), explicit invalidation on write, or write-through (update cache at write time).

Database Sharding

Horizontal partitioning — splitting rows across multiple databases.

By user ID: Shard 0 = users 0-1M, Shard 1 = users 1M-2M, etc.

By geography: US users in US-DB, EU users in EU-DB.

By time: Archive old tweets to cold storage, keep recent in hot storage.

Sharding problems: Cross-shard queries (expensive), hot spots (one celebrity user floods one shard), rebalancing (moving data when shards change).

Message Queues

Why queues? They decouple producers from consumers. If a service is slow, the queue absorbs the backlog. If it crashes, messages aren't lost.

Kafka — High throughput, persistent log, good for event streaming

RabbitMQ — Simpler, message acknowledgments, good for task queues

SQS — AWS managed, pay-per-use, good for decoupling

Google System Design

Google's SDI evaluates two things: Googleyness (how you work, how you handle ambiguity, whether you're a good collaborator) and architectural depth (do you know distributed systems deeply).

What Google Looks For

| Attribute | What It Means |

|-----------|--------------|

| Comfortable with ambiguity | Don't wait for perfect information — make reasonable assumptions and move |

| Collaborative | Check in with interviewer, don't design in a vacuum |

| Impact-oriented | Focus on what matters, not edge cases |

| Technical depth | Understand why, not just what — trade-offs at every layer |

Common Google SDI Problems

• Design Google Search
• Design a URL shortener (like TinyURL)
• Design Google Maps routing
• Design a distributed crawler
• Design Google Drive
• Design a rate limiter

Sample Google Question: Design Google Search

Clarify: "Should I design for crawler/indexing, or just the query/serving layer?" ( interviewers often narrow this)

High-level:

User → CDN → Load Balancer → Query Parser → Index Servers → Document Servers
                                    ↳ Cache (search results)
                                    ↳ Spell Checker

Key decisions:

• Index: Inverted index — word → documents. Use BigTable or similar.
• Ranking: PageRank + 200+ signals. Don't try to explain all signals — pick 5-10 and explain trade-offs.
• Caching: Most searches are repeated. Cache popular queries for 1-10 minutes.
• Spelling: Pre-built dictionary + query log for suggestions.

For full coverage, see Google Maps routing system design and system design interview guide.

Meta System Design

Meta's SDI focuses on product sense — can you design a product that users love? — and scalability — can you make it work for a billion users?

What Meta Looks For

| Attribute | What It Means |

|-----------|--------------|

| Product sense | Do you understand why users want this feature? Can you anticipate how they'll use it? |

| Iterative design | Start simple, then add complexity as needed |

| Data-driven | What metrics would you track? How would you measure success? |

| Ownership mindset | Would you bet your career on this design? |

Common Meta SDI Problems

• Design Instagram
• Design Facebook News Feed
• Design a peer-to-peer payment system (Venmo)
• Design a marketplace
• Design a messaging system

Sample Meta Question: Design Instagram

Clarify: "Photo sharing? Video too? Stories? What's the core use case?"

Key decisions:

1. Photo upload flow:

User → Mobile App → Load Balancer → Photo Service → Object Storage (S3)
                                          ↳ Metadata DB (user, location, tags)

1. Feed generation:

• Pull model: Build feed on request by pulling followed users' posts
• Push model: Fan-out on write — push posts to followers' caches
• Hybrid: Push for celebrities (many followers), pull for regular users

1. Storage:

• Photos: Object storage (S3)
• Feed cache: Redis
• User/graph data: SQL or TAO (Facebook's graph DB)

For full coverage, see LinkedIn feed ranking system design and Twitter trending topics.

Amazon System Design

Amazon's SDI evaluates Leadership Principles in action — not as a checklist, but as a lens on your architectural decisions.

What Amazon Looks For

Every decision you make reflects an LP. Name them explicitly:

| Decision | Leadership Principle |

|----------|---------------------|

| "I'll design for 10x scale, not infinite scale" | Bias for Action — move fast, don't over-engineer |

| "I'll track the metric and iterate" | Deliver Results — measurable outcomes |

| "The customer can always return the item" | Customer Obsession |

| "I'll design the simplest thing that works first" | Invent and Simplify |

| "I need to understand the outage impact before deciding" | Are Right, A Lot — data before decisions |

Common Amazon SDI Problems

• Design Amazon's recommendation engine
• Design a shopping cart
• Design an e-commerce platform
• Design a fraud detection system
• Design a warehouse management system

Sample Amazon Question: Design a Recommendation Engine

Start with: "Who is the customer? A first-time visitor or an existing Prime member with purchase history?"

Approach:

1. Content-based filtering — "Users who bought X also bought Y"
2. Collaborative filtering — "Users with similar purchase history bought the same things"
3. Hybrid — Combine both

Scale to Amazon:

• Offline computation: Pre-compute recommendations nightly (too expensive to do real-time)
• Online serving: Serve pre-computed recommendations from cache
• A/B test: Show recommendations to 1% of users, measure click-through and conversion

For full coverage, see system design recommendation engine and e-commerce platform guide.

Netflix System Design

Netflix's SDI is unique because reliability is the product. When you're streaming to 200 million subscribers, a 1% availability drop means 2 million people can't watch. This shapes every architectural decision.

What Netflix Looks For

| Attribute | What It Means |

|-----------|--------------|

| Availability over consistency | Prefer letting users stream even if recommendations are slightly stale |

| Chaos engineering | Would you deliberately break your own system to find weaknesses? |

| Graceful degradation | What happens when a service goes down? Can the system still stream? |

| Cost awareness | Netflix runs at massive scale — every optimization is worth millions |

Common Netflix SDI Problems

• Design Netflix
• Design a video streaming service
• Design a content delivery network
• Design a recommendation system at Netflix scale

Sample Netflix Question: Design Netflix

Key architectural layers:

1. Content ingestion:

Studio → Encoding (multiple bitrates) → Storage (S3) → CDN

1. Streaming:

User → Open Connect (Netflix CDN) → Streaming Server → Adaptive Bitrate (ABR)

1. Recommendations:

• Compute nightly on Hadoop cluster
• Serve from Redis cache
• Fallback to popularity-based recommendations if personalized fails

1. Resilience patterns:

• Circuit breaker: If recommendation service is slow, serve fallback
• Bulkhead: Isolate failures — if one feature fails, others continue
• Canary: Roll out to 1% before 100%

For full coverage, see Netflix personalization system design and video streaming platform.

15 Real-World Systems to Master

These are the most commonly asked SDI problems, ranked by frequency:

| # | System | Difficulty | Company Frequency |

|---|--------|-----------|------------------|

| 1 | Design Twitter | Medium-Hard | Google, Meta, Amazon |

| 2 | Design URL Shortener | Easy-Medium | Amazon, Google |

| 3 | Design a Chat System | Medium-Hard | Meta, Google |

| 4 | Design a Video Streaming Service | Hard | Netflix, Amazon |

| 5 | Design an E-Commerce Platform | Medium-Hard | Amazon, Walmart |

| 6 | Design a Rate Limiter | Medium | Google, Stripe |

| 7 | Design a Distributed Cache | Hard | Netflix, Amazon |

| 8 | Design a Payment System | Hard | Stripe, Amazon |

| 9 | Design a Search Engine | Hard | Google, Amazon |

| 10 | Design a Ride-Sharing App | Medium-Hard | Uber, Lyft |

| 11 | Design a Social Media Feed | Medium-Hard | Meta, Twitter |

| 12 | Design a Recommendation Engine | Medium-Hard | Netflix, Amazon |

| 13 | Design a Notification System | Easy-Medium | Amazon, Google |

| 14 | Design a Distributed Database | Hard | Google, Amazon |

| 15 | Design a CDN | Medium-Hard | Netflix, Akamai |

Quick Links to Each System

| System | Deep Dive Guide |

|--------|----------------|

| Twitter | Twitter Trending Topics |

| Chat System | Real-Time Chat |

| Video Streaming | Video Streaming Platform |

| Rate Limiter | Rate Limiting Guide |

| Distributed Cache | Distributed Cache Guide |

| Payment System | Payment System Guide |

| Search Engine | Search Engine Guide |

| Ride-Sharing | Ride-Sharing Guide |

| Social Feed | Social Media Feed |

| Recommendation Engine | Recommendation Engine |

| Notification System | Notification System |

| E-Commerce | E-Commerce Platform |

| CDN | Global CDN |

| Distributed Database | Interview System Design Databases |

| URL Shortener | URL Shortener Guide |

System Design Interview Checklist

Before your interview, verify you can explain:

Fundamentals

• [ ] CAP Theorem and its implications
• [ ] SQL vs. NoSQL trade-offs
• [ ] Load balancing strategies
• [ ] Caching strategies and invalidation
• [ ] Database sharding strategies
• [ ] Message queue use cases

Architecture Patterns

• [ ] Microservices vs. monolith trade-offs
• [ ] Event-driven architecture
• [ ] CQRS (Command Query Responsibility Segregation)
• [ ] Proxy vs. reverse proxy
• [ ] API Gateway patterns

Scalability

• [ ] Horizontal vs. vertical scaling
• [ ] Read replicas vs. primary database
• [ ] Database indexing strategies
• [ ] CDN and edge caching
• [ ] Stateless services

Reliability

• [ ] Circuit breaker pattern
• [ ] Retry strategies and exponential backoff
• [ ] Bulkhead isolation
• [ ] Graceful degradation
• [ ] Health checks and monitoring

System Design FAQ

How long should I spend on the clarification step?

5 minutes maximum. Interviewers will redirect you if you take longer. The goal is to identify constraints — once you have them, move.

Should I draw a diagram?

Yes. A simple box-and-arrow diagram is the fastest way to communicate your architecture. Don't worry about perfect diagrams — sketch the major components and label them.

What if I don't know the answer?

Say so honestly: "I haven't worked with X at scale — but my intuition would be..." Show your reasoning, not just your knowledge. Interviewers value honest problem-solving over pretending.

Is it okay to ask the interviewer for hints?

Yes. "Would it help to focus on the read path or the write path?" is a reasonable clarification question. What you can't do is ask "what's the right answer" — that's not what the interview is testing.

How do I handle a problem I haven't seen?

Apply the framework. Any system — even one you've never thought about — fits the same structure: clarify requirements, design the API, choose storage, identify bottlenecks, scale. The framework is the constant; the system is the variable.

30-Day System Design Prep Plan

Week 1: Foundation

Days 1-2: Read this guide. Understand the framework.

Days 3-4: Study CAP theorem, SQL vs. NoSQL, caching patterns.

Days 5-7: Practice with 3 easy problems (URL shortener, notification system, rate limiter).

Week 2: Common Systems

Days 8-10: Design Twitter, a chat system, and a feed system.

Days 11-13: Study distributed caching, message queues, database sharding.

Days 14: Review your weak areas.

Week 3: Advanced Systems

Days 15-17: Design video streaming, search engine, recommendation engine.

Days 18-19: Study chaos engineering, circuit breakers, graceful degradation.

Days 20-21: Practice explaining trade-offs out loud.

Week 4: Mock Interviews + Company Prep

Days 22-24: Do 3 mock SDIs (with a friend, coach, or an AI practice tool).

Days 25-27: Company-specific prep — review your target company's common problems.

Days 28-30: Light review. Practice talking through one problem per day. Get sleep.

Explore Related Topics

• Ultimate Guide to Behavioral Interviews in 2026: Everything You Need to Know
• Amazon Leadership Principles Interview: Guide with...
• Complete Guide to Amazon Software Engineer Interviews (2026)

Practice with AI

The best way to prepare for system design interviews is to practice under pressure — explaining your architecture out loud, answering follow-up questions, and defending your trade-offs. CodeSwiftr's AI interview simulator runs you through real SDI problems with feedback on your communication, depth, and trade-off reasoning.

Practice system design interviews →