System Design
The Complete System Design Interview Guide: From Foundations to Production
Introduction: Why System Design Matters
System design interviews have become a crucial part of technical hiring at major tech companies. Unlike coding interviews that test algorithmic thinking, system design interviews evaluate your ability to build scalable, reliable, and maintainable systems. This comprehensive guide serves as your pivot point to master the concepts, patterns, and tradeoffs that form the backbone of modern distributed systems.
Whether you're aiming for a role at FAANG companies or scaling startups, understanding system design isn't just about passing interviews—it's about building systems that users love and can rely on.
Part 1: ⚙️ Core Concepts — The Foundation You Can't Skip
Before diving into complex architectures, you need to understand the fundamental principles that govern all distributed systems.
Understanding System Properties
Scalability is about your system's ability to handle growing workloads. When we talk about scalability, we're asking: "Can my system handle 10x more users? 100x more data?" It's not just about adding hardware; it's about designing systems that grow efficiently. Think of LinkedIn: when they went from millions to billions of members, every architectural decision had to scale horizontally.
Availability measures the percentage of time your system is operational. In business terms, this is often expressed as "nines"—99% (two nines), 99.9% (three nines), or 99.99% (four nines). A system with 99% availability means roughly 3.65 days of downtime per year. High availability requires redundancy, automatic failover mechanisms, and careful monitoring.
Reliability goes beyond availability—it's about your system consistently doing what it's supposed to do without failing. A reliable system gracefully handles partial failures, data corruption, and unexpected load spikes. It's the difference between a system that's "up" and a system that actually works when it matters.
Single Point of Failure (SPOF) is any component whose failure brings down the entire system. Identifying and eliminating SPOFs is a primary goal of system design. If your database is your only instance, it's a SPOF. If your load balancer has no backup, that's a SPOF. Good architecture means every critical component has redundancy.
Latency vs Throughput vs Bandwidth are often confused but represent different dimensions:
- Latency: Time to process a single request (milliseconds matter here)
- Throughput: Number of requests you can handle per unit time (requests/second)
- Bandwidth: Maximum data flow rate (Mbps or Gbps)
A fast car (low latency) doesn't necessarily mean it can transport many passengers (throughput), and a wide highway (bandwidth) doesn't determine how quickly you reach your destination (latency).
Distribution and Consistency
Consistent Hashing solves a fundamental problem in distributed systems: "How do I distribute data across multiple servers so that when I add or remove a server, I don't have to rehash everything?" Traditional modulo hashing creates this problem—if you go from 10 to 11 servers, most keys need to move. Consistent hashing minimizes this with a virtual ring, ensuring only a fraction of keys need remapping. This is essential for distributed caches and databases like Memcached and Redis clusters.
CAP Theorem states that any distributed system can guarantee only two of three properties:
- Consistency: All nodes see the same data
- Availability: System remains operational under failures
- Partition tolerance: System survives network partitions
Understanding CAP isn't about memorizing definitions—it's about recognizing that you must make intentional tradeoffs. When a network partition occurs, you choose between consistency (refusing writes) or availability (accepting writes that may conflict).
Fault Tolerance and Recovery
Failover is the automatic process of switching to a backup system when the primary fails. Active-passive failover keeps a standby ready; active-active shares the load between primary and backup. Implementing failover requires robust health checking, fast detection of failures, and mechanisms to prevent split-brain scenarios where both systems think they're primary.
Fault Tolerance is your system's ability to continue operating even when components fail. It's achieved through redundancy (having backups), monitoring (knowing when something's wrong), and recovery mechanisms (fixing problems automatically or quickly). A truly fault-tolerant system degrades gracefully—it doesn't crash; it just performs worse until repairs are complete.
Part 2: 🌐 Networking Fundamentals — The Internet's Plumbing
Understanding networking is critical because every distributed system communicates over a network.
The Protocol Stack
OSI Model provides a seven-layer framework for understanding network communication:
- Physical (cables and signals)
- Data Link (MAC addresses)
- Network (IP routing)
- Transport (TCP/UDP)
- Session (connections)
- Presentation (encryption/compression)
- Application (HTTP, emails, etc.)
When designing systems, you typically care about layers 4-7. Understanding which layer handles what helps you make better architectural decisions.
IP Addresses are your system's identity on the network. IPv4 (32-bit, like 192.168.1.1) is running out of addresses, so IPv6 (128-bit) is increasingly important. In system design, understanding public vs. private IPs, CIDR notation, and subnetting helps you plan your network architecture. VPCs and subnetting strategies directly impact your system's security and scalability.
Domain Name System (DNS) translates human-readable names (google.com) into IP addresses. DNS is often the first step in every web request, making it critical to understand. DNS caching, TTL (Time To Live), and DNS resolution strategies impact both performance and your ability to do blue-green deployments. A DNS failure cascades—if DNS is down, your users can't reach you at all.
Proxy vs Reverse Proxy are often confused:
- Proxy: Acts on behalf of clients, hiding their identity from servers
- Reverse Proxy: Acts on behalf of servers, hiding them from clients
Reverse proxies are fundamental to modern architecture—they handle SSL termination, load balancing, request routing, and caching. Products like Nginx and HAProxy do this job.
HTTP/HTTPS is the protocol powering the web. HTTP is stateless and human-readable but insecure; HTTPS adds encryption via TLS. Understanding HTTP status codes, methods (GET, POST, PUT, DELETE), headers, and connection management is essential. Modern systems also use HTTP/2 (multiplexing) and HTTP/3 (QUIC).
TCP vs UDP represent different transport layer approaches:
- TCP: Reliable, ordered, connection-based. Used for email, HTTP, databases
- UDP: Fast, connectionless, unreliable. Used for VoIP, games, DNS queries
Your choice depends on whether reliability or speed matters more. Real-time video streams can tolerate lost packets; financial transactions cannot.
Traffic Management
Load Balancing distributes incoming requests across multiple servers. Load balancing strategies include:
- Round-robin: Simple, treats all servers equally
- Least connections: Routes to server with fewest active connections
- IP hash: Same client always routes to same server
- Weighted: Route more traffic to more powerful servers
Load balancers can operate at Layer 4 (TCP/UDP) or Layer 7 (application). Layer 7 is more flexible but more resource-intensive.
Checksums verify data integrity. When data is transmitted across networks, bit-flipping can occur. Checksums (simple parity checks) or cryptographic hashing (SHA-256) ensure data wasn't corrupted. Understanding error detection and correction helps you design systems that catch and handle corruption gracefully.
Part 3: 🔌 API Fundamentals — Your System's Interface
Your API is your system's contract with the world. Get it right, and you're golden; get it wrong, and you're stuck maintaining backwards compatibility forever.
API Design and Communication
APIs (Application Programming Interfaces) define how different software components communicate. In system design, you're often designing internal APIs between services or external APIs for clients. Good API design is about clarity, consistency, and future-proofing.
API Gateway is the single entry point for all client requests in microservices architectures. It handles:
- Authentication and authorization
- Rate limiting and quota management
- Request/response transformation
- Routing to appropriate microservices
- Logging and monitoring
Products like Kong, AWS API Gateway, and Tyk provide these features out of the box.
REST vs GraphQL represent two API paradigms:
- REST: Resource-based, follows HTTP semantics, multiple endpoints
- GraphQL: Query-based, single endpoint, clients request exactly what they need
REST is simpler to implement and cache; GraphQL is more flexible but can complicate backend optimization. Many companies use both—REST for simple clients, GraphQL for complex frontends.
WebSockets enable bidirectional communication over a single TCP connection. Unlike HTTP's request-response model, WebSockets maintain persistent connections, enabling real-time features like chat, notifications, and live updates. This requires different backend architecture—you need connection managers and a way to broadcast messages to multiple connections.
Webhooks reverse the typical client-server relationship—instead of clients polling for updates, servers push notifications to clients via HTTP callbacks. Webhooks require you to handle retry logic, exponential backoff, and ensure idempotency (more on that below).
Reliability and Resilience
Idempotency means an operation produces the same result whether executed once or multiple times. This is crucial for reliability. If a payment service crashes after processing a transaction but before sending confirmation, will your retry process duplicate the charge? Good systems ensure operations are idempotent by using idempotency keys.
Rate Limiting protects your system from overload and abuse. Common strategies include:
- Token bucket: Allows bursts while maintaining average rate
- Sliding window: Tracks requests in a time window
- Fixed window: Simple but allows bursts at boundaries
Rate limiting should be explicit (users know their limits) and graceful (return 429 Too Many Requests with retry information).
API Design Best Practices include:
- Versioning: /v1/, /v2/ allows evolution without breaking clients
- Error handling: Consistent error response formats
- Pagination: Never return millions of results at once
- Filtering and sorting: Reduce data transfer
- Caching headers: Leverage HTTP caching
- Documentation: Your API is only as good as its documentation
Part 4: 🗄️ Database Fundamentals — Your Source of Truth
Databases are where your data lives, and choosing the right database strategy is one of the most critical architectural decisions.
Core Database Concepts
ACID Transactions define database reliability:
- Atomicity: All or nothing (all writes succeed or all rollback)
- Consistency: Database moves from one valid state to another
- Isolation: Concurrent transactions don't interfere
- Durability: Committed data survives failures
ACID is expensive to maintain; many NoSQL databases sacrifice some ACID properties for performance. Understanding these tradeoffs is key to choosing the right database.
SQL vs NoSQL represents a fundamental architectural choice:
- SQL: Structured schema, ACID, strong consistency, complex queries
- NoSQL: Flexible schema, eventual consistency, horizontal scaling
There's no winner—use SQL for financial systems and NoSQL for content-heavy applications. Many successful systems use both.
Database Indexing speeds up queries but slows down writes. Indexes are essentially sorted data structures that allow the database to find data without scanning every row. B-trees are common for SQL; LSM trees for NoSQL. Choosing what to index is a balancing act—index what you query, but not everything.
Scaling Databases
Database Sharding horizontally partitions data across multiple database instances. Sharding strategies include:
- Range-based: Shard 1 has users 1-1M, Shard 2 has 1M-2M
- Hash-based: Hash(user_id) % num_shards determines shard
- Directory-based: A lookup service maps keys to shards
Sharding is powerful but complex—it complicates transactions, joins, and rebalancing.
Data Replication copies data across multiple servers for redundancy and read scaling. Replication strategies include:
- Single-leader: One server accepts writes, replicates to followers
- Multi-leader: Multiple servers accept writes, coordinate changes
- Leaderless: Any server can accept writes
Each strategy has tradeoffs between consistency, availability, and complexity.
Database Scaling Strategies include:
- Vertical scaling: Bigger server (limited by physics)
- Read replicas: Scale reads by replicating data
- Caching layers: Serve frequently accessed data from cache
- Sharding: Distribute data across servers
- Denormalization: Duplicate data to avoid joins
Database Types beyond SQL and NoSQL:
- Key-value stores (Redis): Ultra-fast, in-memory
- Document databases (MongoDB): JSON-like storage
- Column-family stores (Cassandra): Optimized for analytics
- Search engines (Elasticsearch): Full-text search
- Time-series databases (InfluxDB): Optimized for metrics
- Graph databases (Neo4j): Optimized for relationships
Different tools for different jobs—use the right one for your use case.
Bloom Filters are probabilistic data structures that answer "Is this element in the set?" with never a false negative but possibly false positives. They use minimal memory, making them perfect for "does this key exist?" checks before expensive lookups. Big data systems use Bloom filters extensively.
Database Architectures patterns include:
- Active-passive: One primary, standby takeover on failure
- Active-active: Multiple instances accept writes, coordinate
- Hub-and-spoke: Central database with satellites
- Read-write separation: Different instances for reads and writes
Part 5: ⚡ Caching Fundamentals — The Speed Layer
Caching is how you make systems fast. Without caching, even the best architecture will feel slow.
Caching Strategy
Caching 101 starts with understanding that caching trades space for time. You store data closer to where it's needed, accepting memory overhead to reduce latency. The cache hit ratio (percentage of requests served from cache) directly impacts performance.
Caching Strategies define when and how to cache:
- Write-through: Write to cache and database immediately. Slower writes, consistency guaranteed.
- Write-behind (write-back): Write to cache immediately, batch writes to database. Faster but risks data loss.
- Cache-aside (lazy loading): Application checks cache; on miss, loads from database and updates cache. Common but application complexity.
Each has tradeoffs between write latency and data safety.
Cache Eviction Policies determine what to remove when cache is full:
- LRU (Least Recently Used): Remove least recently accessed item
- LFU (Least Frequently Used): Remove least frequently accessed item
- FIFO (First In First Out): Remove oldest item
- TTL (Time To Live): Remove expired items
- Random: Random removal
LRU is most common; it works well for most access patterns.
Distributed Caching extends caching across multiple servers. Using consistent hashing, each server in the cache cluster owns certain keys. If a server fails, other servers rebalance the load. Distributed caches like Memcached and Redis are essential for scaling reads in massive systems.
Content Delivery Network (CDN) is global-scale caching for static content. CDNs distribute your content to servers worldwide, ensuring users download from geographically close servers. This dramatically reduces latency for users far from your origin server. Understanding cache headers (Cache-Control, ETag) and invalidation strategies is crucial for CDN effectiveness.
Part 6: 🔄 Asynchronous Communication — Decoupling for Scale
Synchronous communication (request-response) is simple but brittle. Asynchronous patterns decouple systems, allowing them to evolve independently.
Event-Driven Patterns
Pub/Sub (Publish-Subscribe) decouples producers and consumers of events:
- Producers publish events without knowing who consumes them
- Consumers subscribe to event types
- Message broker intermediates
This enables loose coupling—changing consumers doesn't require changing producers. Tools like Kafka and RabbitMQ implement this pattern.
Message Queues guarantee message delivery and ordering:
- Producers put messages in a queue
- Consumers process messages at their own pace
- Failed consumers can retry
Queues protect you from traffic spikes—if your database can handle 1000 requests/second but receive 10000, a queue absorbs the spike and processes gradually.
Change Data Capture (CDC) captures database changes and streams them to other systems. Instead of each system directly querying the database, a CDC pipeline detects inserts/updates/deletes and publishes events. This enables real-time data warehousing and keeps distributed systems synchronized.
Part 7: 🧩 Distributed Systems and Microservices — The Complexity Layer
Distributed systems are the reality of building at scale, but they introduce significant complexity.
Distributed Coordination
HeartBeats are periodic signals from components indicating they're alive. In a distributed system, nodes use heartbeats to detect failures. If Node A doesn't receive a heartbeat from Node B for 30 seconds, it assumes Node B is dead. Heartbeat frequency and timeout duration determine how quickly you detect failures—trade off between responsiveness and false positives.
Service Discovery solves the problem: "How do I know where a service is running?" Services are dynamic—they crash, restart, scale up/down. Service registries (Consul, Eureka, Kubernetes) maintain updated lists of available services. When a service needs to call another, it queries the registry. This enables dynamic load balancing and rolling updates.
Consensus Algorithms let distributed nodes agree on state despite failures. Raft is popular for leader election; Paxos for state machine replication. Consensus requires that a majority of nodes agree, so it tolerates (n-1)/2 failures. The cost is latency—reaching consensus takes multiple network rounds.
Distributed Locking prevents race conditions in distributed systems. Acquire a lock before modifying shared state, release after. Challenges include:
- Network delays: How long is too long for a lock holder to be unreachable?
- Split-brain: What if network partitions create multiple lock holders?
- Deadlocks: Can locks be held forever?
Distributed locks are slow and risky—avoid shared mutable state when possible.
Gossip Protocol spreads information like rumors:
- Each node periodically tells random peers about state changes
- Peers propagate to their peers
- Eventually, everyone knows
Gossip is resilient (no single point of failure), self-healing (new nodes catch up automatically), and works across unreliable networks. Cassandra uses gossip for cluster coordination.
Resilience Patterns
Circuit Breaker prevents cascading failures:
- Closed state: Requests pass through normally
- Open state: Requests fail immediately without calling failed service
- Half-open state: Periodically test if service recovered
When Service A calls Service B repeatedly fails, A opens its circuit, stopping requests. This prevents wasting resources on calls that will fail, allowing B time to recover.
Disaster Recovery is your plan when things go catastrophically wrong. It includes:
- RTO (Recovery Time Objective): How long acceptable downtime is
- RPO (Recovery Point Objective): How much data loss is acceptable
- Backup strategies: How frequently and where
- Failover procedures: How to switch to backup
Understanding these metrics helps you build appropriate redundancy.
Distributed Tracing tracks requests across multiple services. Each request gets a trace ID; every service logs with that ID. Tools like Jaeger and Zipkin let you reconstruct request flow, identify slow hops, and correlate events. Essential for debugging microservices.
Part 8: 🖇️ Architectural Patterns — The Big Picture
Patterns provide proven solutions to recurring problems.
System Architecture Styles
Client-Server Architecture is fundamental:
- Client: Requests services
- Server: Processes requests, returns responses
It's simple, widely understood, but creates a bottleneck at the server. Horizontal scaling (multiple servers + load balancing) is the standard mitigation.
Microservices Architecture breaks monoliths into small, independent services:
- Each service has its own database
- Services communicate via APIs or events
- Independent deployment and scaling
Benefits include isolation, independent scaling, and team autonomy. Costs include operational complexity and debugging difficulty.
Serverless Architecture abstracts away infrastructure:
- Write functions, upload to platform
- Platform manages scaling, availability, monitoring
- Pay only for execution time
Serverless is ideal for event-driven workloads and bursty traffic. It's not ideal for always-on services or complex networking.
Event-Driven Architecture is built around events:
- Components emit events on state changes
- Other components react to events
- Enables loose coupling and scalability
Complex to reason about (requires eventual consistency thinking) but powerful for building reactive systems.
Peer-to-Peer (P2P) Architecture distributes responsibility equally:
- No central server; every node is both client and server
- Self-organizing networks
- Highly resilient to failures
P2P enables BitTorrent and blockchain systems but complicates security and consistency.
Part 9: ⚖️ System Design Tradeoffs — The Heart of the Matter
System design is fundamentally about tradeoffs. Recognizing and articulating them separates great designers from good ones.
Fundamental Tradeoffs
Vertical vs Horizontal Scaling:
- Vertical: Bigger server (faster, limited by physics, single point of failure)
- Horizontal: More servers (unlimited scaling, increased complexity)
Most systems eventually need horizontal scaling.
- Concurrency: Many tasks interleaved on one core
- Parallelism: Many tasks simultaneously on multiple cores
Concurrency is useful for I/O-bound work (database queries); parallelism for CPU-bound work (calculations).
- Long polling: Client polls server, server delays response
- WebSockets: Persistent bidirectional connection
WebSockets enable real-time features but require more infrastructure.
- Batch: Process large volumes of data periodically
- Stream: Process data as it arrives
Batch is simpler and cheaper; streaming provides real-time insights.
- Stateless: No information retained between requests
- Stateful: Server remembers client state
Stateless is easier to scale (any server can handle any request); stateful is simpler to implement.
Strong vs Eventual Consistency:
- Strong: All nodes always have the same data
- Eventual: Nodes eventually have the same data
Strong consistency requires coordination (slower); eventual consistency is faster but requires application logic to handle inconsistencies.
Read-Through vs Write-Through Cache:
- Read-through: Application checks cache on read
- Write-through: Cache updates with every write
Read-through risks cache misses; write-through ensures consistency.
- Push: Server initiates data transfer to clients
- Pull: Clients request data from server
Push is real-time but complex; pull is simpler but requires polling.
- REST: Resource-oriented, HTTP semantics
- RPC: Procedure-oriented, makes remote calls look local
REST is simpler to cache and reason about; RPC is simpler to implement.
Synchronous vs Asynchronous Communication:
- Synchronous: Caller waits for response
- Asynchronous: Caller continues; response arrives later
Synchronous is simpler but creates coupling; asynchronous decouples but is harder to debug.
Latency vs Throughput Optimization:
- Latency: Optimize single-request performance
- Throughput: Optimize requests per second
You often can't have both—batching improves throughput but hurts latency.
Part 10: ✅ How to Answer a System Design Interview Problem
System design interviews follow a pattern. Mastering this framework separates successful candidates.
The Interview Framework
The classic framework takes 45-60 minutes:
1. Clarify Requirements (5-10 minutes)
- Functional requirements: What should the system do?
- Non-functional requirements: Scale, latency, availability targets?
- Number of users, data volume, growth rate?
- Geographic distribution?
Don't assume—ask. The interviewer will provide hints.
2. Estimate Scale (5-10 minutes)
- Back-of-envelope calculations
- QPS (queries per second): Users × requests per user per day ÷ 86400 seconds
- Data volume: How much data to store?
- Bandwidth: Data transferred per second?
These numbers drive architectural decisions.
3. High-Level Design (10-15 minutes)
- Draw boxes and lines representing services
- Data flow: Where does data come from, where does it go?
- Identify major components: Load balancers, databases, caches, etc.
Keep it simple; you'll add details next.
4. Deep Dive (15-20 minutes)
- Choose 1-2 components to explore in detail
- Interviewer may guide you: "Let's talk about the database."
- Discuss tradeoffs, alternative approaches
- Be specific: "We'd use MySQL with read replicas" not just "database"
Don't try to deep dive on everything—you'll run out of time.
5. Handle Failures (5 minutes)
- What if a server fails?
- What if the database loses data?
- What if there's a network partition?
Discuss recovery mechanisms and communication protocols.
6. Recap and Ask for Feedback (remaining time)
- Summarize your design
- Ask the interviewer if anything stood out
- Be prepared to modify based on feedback
Common Patterns to Recognize
- High read/write ratio: Add caching, read replicas, CDN
- Need for consistency: Master-slave replication, transactions
- Billions of small records: Sharding, denormalization
- Real-time updates: WebSockets, Pub/Sub, event streams
- Complex queries: SQL database, analytical data warehouse
- Geographic distribution: Geo-sharding, edge computing
Part 11: 💻 System Design Interview Problems
Practice problems are your proof of understanding. Start with easy problems to build confidence, progress through medium difficulty, and tackle hard problems.
Easy Problems (Get the Basics Right)
These test whether you understand fundamental concepts:
Design URL Shortener like TinyURL
- Core concepts: Database design, API design, unique ID generation
- Database: Store mapping of short URL → long URL
- Scale: Billions of URLs, need high availability
- Tradeoff: Simple but teaches database indexing and sharding
Design Autocomplete for Search Engines
- Core concepts: Trie data structures, caching, ranking
- Database: Cache top searches by prefix
- Real-time: Update rankings as queries come in
- Scale: Billions of users, millisecond latency requirements
- Core concepts: Load balancing algorithms, health checking
- Algorithms: Round-robin, least connections, session affinity
- Failure handling: Detect dead servers, automatic recovery
- Distribution: Session persistence for stateful backends
Design Content Delivery Network (CDN)
- Core concepts: Geographic distribution, caching, DNS
- Architecture: Origin server, edge servers, cache hierarchy
- Optimization: Cache invalidation, cost optimization
- Real-time: Handle regional failures
- Core concepts: Object-oriented design, state management
- Entities: Parking lot, level, spot, vehicle
- Operations: Find available spot, check in/out
- Scale: Large parking structures
- Core concepts: State machines, payment processing
- States: Idle, money accepted, dispensing
- Error handling: Failed payments, out of stock
- Security: Money counting, fraud detection
Design Distributed Key-Value Store
- Core concepts: Sharding, replication, consistency
- Architecture: Multiple servers, consistent hashing
- Operations: Get, Put with replication
- Failure: Handle server failures, data recovery
- Core concepts: Cache eviction, consistent hashing, TTL
- Architecture: Multiple cache nodes, distributed hash table
- Performance: Minimize latency, maximize hit ratio
- Resilience: Handle node failures, client retry logic
- Core concepts: Sessions, tokens, security
- Approach: Session-based vs JWT tokens
- Scale: Distributed session store
- Security: Hashing, salting, rate limiting
Design Unified Payments Interface (UPI)
- Core concepts: Payment processing, security, reliability
- Architecture: Multiple banks, payment gateway
- Consistency: ACID transactions across systems
- Scale: Millions of transactions per day
Medium Difficulty Problems (Combine Multiple Concepts)
These require selecting appropriate tools and combining patterns:
- Messaging: Pub/Sub for message delivery
- Presence: Real-time user online status
- Reliability: Message delivery guarantees
- Scale: Billions of messages daily
- Content: Library of millions of songs
- Recommendations: Personalization engine
- Streaming: Media delivery, CDN integration
- Scale: Hundreds of millions of concurrent streams
- Storage: Billions of images
- Feed: Real-time personalized content
- Social: Following, likes, comments
- Scale: Billions of daily active users
- Delivery: Push, SMS, email notifications
- Scheduling: Delayed notifications
- Routing: User preferences (quiet hours, channels)
- Scale: Billions of notifications daily
Design Distributed Job Scheduler
- Scheduling: Cron-like job scheduling
- Distribution: Run jobs across many servers
- Failure: Retry failed jobs, dead letter queue
- Monitoring: Track job execution
- Matching: Algorithm to find compatible users
- Real-time: Live matching, notifications
- Scale: Millions of users
- Privacy: Hide mutual rejection
- Social graph: Billions of relationships
- Feed: Personalized content ranking
- Scale: Billions of users
- Complexity: Most complex platform
- Feed: Timeline aggregation
- Search: Full-text search on tweets
- Trends: Real-time trending topics
- Scale: Hundreds of millions of tweets daily
- Communities: Subreddits with different moderators
- Ranking: Sorting posts by score, time
- Scale: Hundreds of thousands of active communities
- Complexity: Community-specific rules
- Content: Millions of videos
- Recommendation: Personalization at scale
- Streaming: Video encoding, adaptive bitrate
- Scale: Millions of concurrent viewers
- Upload: Process and encode videos
- Search: Full-text search on video metadata
- Recommendations: Recommendation engine
- Scale: Hundreds of thousands of uploads daily
- Indexing: Crawl and index web
- Search: Query billions of pages in milliseconds
- Ranking: PageRank and relevance algorithms
- Scale: Trillions of web pages
Design E-commerce Store like Amazon
- Catalog: Millions of products
- Cart: Stateful shopping experience
- Transactions: Payment processing
- Scale: Millions of concurrent shoppers
- Video: Short video content
- Recommendation: Algorithm driving engagement
- Feed: Real-time personalized feed
- Scale: Billions of videos
- Multi-tenant: Thousands of independent stores
- Catalog: Millions of products across stores
- Checkout: Reliable transaction handling
- Scale: Black Friday spikes
- Search: Search by location, dates, amenities
- Inventory: Real-time booking availability
- Pricing: Dynamic pricing
- Scale: Millions of listings worldwide
- Algorithm: Token bucket, sliding window
- Distribution: Rate limit across servers
- User-facing: Return clear 429 responses
- Scale: Millions of clients
Design Distributed Message Queue like Kafka
- Durability: Persist messages to disk
- Ordering: Preserve message order within partition
- Scale: Millions of messages per second
- Consumer groups: Multiple consumers
- Search: Query flights by dates, airports
- Booking: Transaction-like guarantees
- Inventory: Real-time seat availability
- Scale: Millions of searches, thousands of bookings daily
- Collaboration: Multiple users editing simultaneously
- Real-time: Live cursor positions, syntax highlighting
- Execution: Run code on backend
- Scale: Hundreds of concurrent sessions
Design Analytics Platform (Metrics & Logging)
- Ingestion: Billions of events daily
- Storage: Efficient time-series storage
- Querying: Complex analytical queries
- Real-time: Real-time dashboards
- Transactions: ACID guarantees
- Routing: Route to appropriate bank/processor
- Reconciliation: Verify transaction success
- Scale: Millions of transactions daily
- Accounts: User balance tracking
- Transfers: P2P money transfer
- Transactions: Recording all movements
- Scale: Millions of wallets
Hard Problems (Test Mastery)
These require deep architectural thinking and handling edge cases:
Design Location-Based Service like Yelp
- Geospatial: Search nearby businesses
- Indexing: Geo-indexing for fast queries
- Scale: Billions of locations worldwide
- Complexity: Accurate distance calculations
- Real-time: Driver-rider matching
- Geospatial: Finding nearest drivers
- Scale: Millions of concurrent drivers/riders
- Complexity: Surge pricing, optimal routing
Design Food Delivery App like Doordash
- Ordering: Accept and route orders
- Delivery: Assign drivers optimally
- Scale: Millions of orders daily
- Complexity: Estimated delivery times
- Collaboration: Real-time editing
- Consistency: Handle concurrent edits
- Conflict resolution: Operational transformation
- Durability: Save every keystroke
- Maps: Store and serve map data
- Routing: Calculate best routes
- Scale: Global coverage
- Real-time: Live traffic updates
- Video: Real-time video/audio communication
- Codec: Efficient video compression
- Scale: Millions of concurrent calls
- Reliability: Handle network quality changes
Design File Sharing System like Dropbox
- Sync: Synchronize files across devices
- Versioning: Keep file history
- Scale: Billions of files
- Deduplication: Save storage with content hashing
Design Ticket Booking System like BookMyShow
- Inventory: Real-time seat availability
- Transactions: Lock seats, handle failures
- Scale: Millions of bookings
- Concurrency: Handle simultaneous bookings
Design Distributed Web Crawler
- Crawling: Fetch and parse web pages
- Distribution: Distribute crawling across servers
- Politeness: Respect robots.txt
- Scale: Crawl billions of pages
- Deployment: Deploy code to thousands of servers
- Rollback: Revert failed deployments
- Health checking: Verify deployment success
- Scale: Deploy to global infrastructure
Design Distributed Cloud Storage like S3
- Reliability: 99.99999999% availability
- Scalability: Petabytes of data
- Durability: Data never lost
- Consistency: Eventually consistent
Design Distributed Locking Service
- Consensus: Agreement on lock ownership
- Deadlock prevention: Timeout mechanisms
- Scale: Millions of locks
- Failure recovery: Handle dead processes
Conclusion: Your Path to Mastery
System design is learned through study and practice. This guide provides the foundation; your success comes from:
- Understand the fundamentals: Deeply learn each core concept. Don't just memorize definitions.
- Practice problems progressively: Start easy, work up to hard. Each problem teaches different concepts.
- Learn from real systems: Read blogs from Netflix, Amazon, LinkedIn engineers about their systems.
- Communicate clearly: In interviews, explain your thinking. Tradeoffs matter more than perfection.
- Stay current: System design evolves. Follow new technologies and architectural patterns.
Remember: there's no one "correct" answer to a system design problem. What matters is:
- Understanding requirements and constraints
- Making justified tradeoffs
- Building solutions that are reliable, scalable, and maintainable
- Communicating your reasoning
The best engineers don't know everything—they know how to think systematically about complex problems. This guide teaches you that thinking.
Good luck with your interviews. You've got this.
Additional Resources for Continued Learning
- Follow engineers' blogs from major tech companies
- Study papers on distributed systems fundamentals
- Contribute to open-source distributed systems projects
- Conduct mock interviews with peers
- Revisit concepts you struggle with—they always appear in interviews
Last Updated: July 26, 2026
This guide is designed to be your pivot point for system design mastery. Start with the concepts, progress through the problems, and master the art of building systems at scale.