System design interviews separate senior engineers from junior ones. While coding interviews test problem-solving, system design tests your ability to think at scale—to architect systems handling millions of users and complex trade-offs.

This guide covers 25 system design interview questions that appear most frequently at Google, Meta, Amazon, and other top companies.

For real-time practice with AI feedback, try Interview AiBox.

URL Shortener
Rate Limiter
Chat System
News Feed
Search Autocomplete
Video Streaming
Key-Value Store
Message Queue
Web Crawler
Notification System
Payment System
E-commerce Platform
Social Media Platform
Ride-Sharing Service
Food Delivery App
Cloud Storage Service
CDN
Distributed Cache
Log Aggregation
Configuration Management
Identity Provider
Analytics Platform
Recommendation System
Ad Click Aggregator
Ticket Booking System

URL Shortener

Problem: Design a service like bit.ly that creates short URLs and redirects to originals.

Key Components:

Hashing: MD5/SHA256 → base62, or counter-based with pre-generated keys
Storage: Redis for hot data, database for persistence
Redirection: 301 or 302 based on analytics needs
Analytics: Async event queue → data warehouse

Trade-offs:

Custom vs. auto-generated short codes
Consistent hashing vs. single database
Cache-aside vs. write-through

Rate Limiter

Problem: Design a rate limiter limiting API requests per user.

Key Components:

Algorithms: Token bucket, sliding window, fixed window
Storage: Redis with atomic operations
Placement: API gateway or application layer

Trade-offs:

Accuracy vs. memory (sliding vs. fixed window)
Distributed vs. local rate limiting
Hard limit vs. soft limit with queueing

Chat System

Problem: Design a real-time chat like WhatsApp.

Key Components:

Connections: WebSocket, HTTP long-polling fallback
Message Queue: Kafka for routing
Storage: NoSQL for messages, SQL for metadata
Presence: Redis pub/sub for online status

Trade-offs:

At-most-once vs. exactly-once delivery
Push vs. pull for messages
End-to-end encryption vs. server processing

News Feed

Problem: Design a news feed like Facebook/Twitter.

Key Components:

Fan-out Models: Pull (generate on read), Push (pre-compute), Hybrid
Storage: Graph DB for connections, cache for feed
Ranking: ML models for relevance

Trade-offs:

Latency vs. freshness
Storage vs. compute cost
Chronological vs. algorithmic ranking

Search Autocomplete

Problem: Design search autocomplete like Google.

Key Components:

Data Structure: Trie or n-gram based
Ranking: Frequency, personalization, trending
Caching: Multi-layer (CDN, app, database)
Updates: Stream processing for real-time

Trade-offs:

Trie size vs. search speed
Real-time vs. batch updates
Personalized vs. global suggestions

Video Streaming

Problem: Design a video platform like YouTube.

Key Components:

Upload: Chunked, resumable, transcoding pipeline
Storage: Object storage + CDN
Streaming: HLS/DASH adaptive bitrate
Transcoding: Multiple resolutions in parallel

Trade-offs:

Quality vs. bandwidth
Live vs. VOD architecture
Central vs. edge transcoding

Key-Value Store

Problem: Design a distributed KV store like DynamoDB.

Key Components:

Partitioning: Consistent hashing with virtual nodes
Replication: Multi-master with quorum
Conflict Resolution: Last-write-wins or vector clocks
Failure Handling: Hinted handoff, anti-entropy

Trade-offs:

Strong vs. eventual consistency (CAP)
Read vs. write optimization
Memory vs. disk-based

Message Queue

Problem: Design a message queue like Kafka.

Key Components:

Storage: Append-only log, indexed by offset
Partitioning: Partition by key for ordering
Replication: Leader-follower with ISR
Consumer Groups: Load balancing across consumers

Trade-offs:

Latency vs. durability (acks settings)
Ordering vs. parallelism
At-least-once vs. exactly-once

Web Crawler

Problem: Design a scalable web crawler.

Key Components:

URL Frontier: Priority queue with politeness
Distributed Workers: Coordinate via message queue
Deduplication: Bloom filter for seen URLs
Storage: Document store, graph DB for links

Trade-offs:

BFS vs. DFS crawling
Freshness vs. coverage
Single vs. distributed

Notification System

Problem: Design multi-channel notifications (email, SMS, push, in-app).

Key Components:

Queue: Priority queues per channel
Workers: Channel-specific delivery services
Templates: Parameterized templates
Tracking: Delivery status, open rates

Trade-offs:

Immediate vs. batched delivery
Guaranteed vs. best-effort
Central vs. per-channel queuing

Payment System

Problem: Design payment processing like Stripe.

Key Components:

Transactions: ACID, idempotency keys
Gateway: Integration with providers
Fraud Detection: ML models, rule engines
Reconciliation: Daily batch processing

Trade-offs:

Sync vs. async processing
Real-time vs. batch fraud detection
Single vs. multiple providers

E-commerce Platform

Problem: Design e-commerce like Amazon.

Key Components:

Catalog: Elasticsearch, denormalized data
Cart: Redis for session, merge on login
Orders: State machine, saga pattern
Inventory: Optimistic locking, reservation

Trade-offs:

Monolith vs. microservices
Strong vs. eventual consistency
Real-time vs. batch inventory

Problem: Design social media like Instagram.

Key Components:

Upload: Pre-signed URLs, async thumbnails
Storage: Object storage + CDN
Feed: Fan-out hybrid model
Graph: Adjacency list or graph DB

Trade-offs:

Storage format (original + variants)
Feed generation timing
Pre vs. post content moderation

Problem: Design ride-sharing like Uber.

Key Components:

Location: Geospatial index (GeoHash, QuadTree)
Matching: Distance-based, ETA-based
Pricing: Surge based on supply/demand
Tracking: WebSocket for real-time

Trade-offs:

Matching complexity vs. speed
Real-time vs. batch pricing
Single vs. multi-hop matching

Food Delivery App

Problem: Design food delivery like DoorDash.

Key Components:

Discovery: Geospatial search, filters
Order: State machine workflow
Assignment: Matching algorithm
Tracking: Real-time GPS updates

Trade-offs:

Single vs. multi-restaurant orders
Pre-assignment vs. on-demand delivery
Restaurant-owned vs. platform fleet

Cloud Storage Service

Problem: Design cloud storage like Dropbox.

Key Components:

Sync: Block-level deduplication, delta sync
Storage: Object storage with metadata DB
Versioning: Immutable blocks, pointer-based
Conflict: Last-write-wins or manual merge

Trade-offs:

Block size vs. metadata overhead
Client vs. server deduplication
Sync frequency vs. battery

CDN

Problem: Design a CDN like Cloudflare.

Key Components:

Edge Servers: Cache static, terminate SSL
Routing: DNS-based or anycast
Cache: LRU with TTL
Origin Shield: Protect from thundering herd

Trade-offs:

Cache hit rate vs. storage cost
Push vs. pull caching
Edge vs. origin processing

Distributed Cache

Problem: Design distributed cache like Redis Cluster.

Key Components:

Sharding: Hash slots or consistent hashing
Replication: Master-slave with failover
Eviction: LRU, LFU, or TTL-based
Client: Smart client for routing

Trade-offs:

Memory vs. eviction rate
Sync vs. async replication
Client-side vs. proxy routing

Log Aggregation

Problem: Design log aggregation like ELK Stack.

Key Components:

Ingestion: Agents → queue → indexers
Storage: Time-series, columnar for analytics
Indexing: Inverted index for text search
Query: Distributed query execution

Trade-offs:

Real-time vs. batch indexing
Storage vs. query performance
Hot vs. cold storage tiering

Configuration Management

Problem: Design config management like etcd.

Key Components:

Consensus: Raft protocol
Storage: MVCC key-value store
Watch: Event-based notification
API: REST or gRPC

Trade-offs:

Read-your-writes vs. stale reads
Linearizable vs. serializable
Embedded vs. standalone

Identity Provider

Problem: Design SSO like Okta.

Key Components:

Auth: MFA, password policies
Protocols: SAML, OAuth, OIDC
Session: JWT, refresh token rotation
Directory: User store, groups

Trade-offs:

Session duration vs. security
Central vs. distributed session
Stateless vs. stateful sessions

Analytics Platform

Problem: Design real-time analytics like Mixpanel.

Key Components:

Ingestion: Kafka → Flink stream processing
Storage: OLAP (ClickHouse, Druid)
Aggregation: Pre-computed + raw events
Query: SQL with visualization

Trade-offs:

Real-time vs. batch processing
Pre-aggregation vs. on-demand
Storage vs. query flexibility

Recommendation System

Problem: Design recommendations like Netflix.

Key Components:

Models: Collaborative filtering, content-based, hybrid
Training: Offline batch, online learning
Serving: Pre-computed candidates + real-time ranking
Features: User, item, interaction features

Trade-offs:

Model complexity vs. latency
Pre-computed vs. real-time
Exploration vs. exploitation

Ad Click Aggregator

Problem: Design real-time ad click counting.

Key Components:

Ingestion: Stream processing pipeline
Deduplication: Bloom filter + exact check
Aggregation: Time-windowed counts
Storage: OLAP for analytics

Trade-offs:

Exact vs. approximate counting
Real-time vs. batch aggregation
Storage vs. query latency

Ticket Booking System

Problem: Design ticket booking like Ticketmaster.

Key Components:

Inventory: Real-time availability, locking
Booking: State machine, timeout for holds
Payment: Idempotent processing
Queue: Virtual waiting room for high demand

Trade-offs:

Optimistic vs. pessimistic locking
Hold timeout duration
Queue vs. first-come-first-served

System Design Framework

Use this 5-step framework for any system design question:

Step 1: Clarify Requirements (5 min)

Functional requirements (what it does)
Non-functional requirements (scale, latency, availability)
Constraints and assumptions

Step 2: Define API (5 min)

Input/output contracts
Error cases
Authentication/authorization

Step 3: High-Level Design (10 min)

Core components
Data flow
Draw a diagram

Step 4: Deep Dive (15 min)

Scaling strategies
Failure modes
Edge cases

Step 5: Trade-offs (5 min)

What you chose and why
What you gave up
Alternative approaches

FAQ

How detailed should my diagrams be?

Start simple: 3-5 core components. Add detail as you discuss trade-offs. Don't draw everything at once—build up your design iteratively.

What if I don't know a specific technology?

Focus on concepts, not tools. Say "a message queue like Kafka" rather than just "Kafka." Interviewers care about your reasoning, not memorized tech stacks.

How do I handle ambiguity?

Ask clarifying questions. "Should we prioritize consistency or availability?" "What's the expected scale?" Good questions show senior-level thinking.

Should I mention specific algorithms?

Yes, when relevant. Mention consistent hashing, Raft, or CAP theorem naturally as you discuss trade-offs. Don't force them in.

How long should my answer be?

35-45 minutes is typical. The framework above fits this timeline. Practice with a timer.

Next Steps

Practice with AI feedback: Try Interview AiBox for real-time system design practice.
Read related guides:
- Top 50 Coding Interview Questions
- 30 Behavioral Interview Questions
Download Interview AiBox and start practicing today.

System design is a skill that improves with practice. Start now.

Interview AiBoxInterview AiBox — Interview Copilot