System Design
Learn System Design
Introduction to System Design
How to Learn System Design?
Key Characteristics of Distributed Systems
Scalability
Availability
Latency and Performance
Concurrency and Coordination
Monitoring and Observability
Resilience and Error Handling
Fault Tolerance vs. High Availability
Flashcards Review
Chapter Assessment
Network Essentials
HTTP vs. HTTPS
TCP vs. UDP
HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0
URL vs. URI vs. URN
What Happens When You Type a URL into the Browser
Flashcards Review
Chapter Assessment
Long-Polling vs. WebSockets vs. Server-Sent Events
Introduction to Real-Time Communication
What is Long-Polling?
What is WebSocket?
What are Server-Sent Events?
Difference Between Long-Polling, WebSockets, and Server-Sent Events
Flashcards Review
Chapter Assessment
Domain Name System (DNS)
Introduction to DNS
DNS Resolution Process
DNS Load Balancing and High Availability
Flashcards Review
Chapter Assessment
Proxies
What is a Proxy Server?
Uses of Proxies
VPN vs. Proxy Server
Flashcards Review
Chapter Assessment
Load Balancing
Introduction to Load Balancing
Load Balancing Algorithms
Uses of Load Balancing
Load Balancer Types
Stateless vs. Stateful Load Balancing
High Availability and Fault Tolerance
Scalability and Performance
Challenges of Load Balancers
Flashcards Review
Chapter Assessment
API Gateway
Introduction to API Gateway
Usage of API gateway
Advantages and disadvantages of using API gateway
Flashcards Review
Chapter Assessment
API Design
What Is an API?
What Are REST APIs?
Resources, Not Actions
HTTP Methods and Their Semantics
URL Design
Request and Response Shapes
Status Codes and Error Design
Pagination from the Consumer's View
Idempotency Keys
Versioning and Backward Compatibility
Concurrency and Conditional Requests
REST vs gRPC vs GraphQL
Flashcards Review
Chapter Assessment
Rate Limiting and Throttling
What Is Rate Limiting
Rate Limiting Algorithms
Distributed Rate Limiting
Rate Limiting in Practice
Flashcards Review
Chapter Assessment
Caching
Introduction to Caching
Why is Caching Important?
Types of Caching
Cache Replacement Policies
Cache Invalidation
Cache Read Strategies
Cache Coherence and Consistency Models
Caching Challenges
Cache Performance Metrics
Flashcards Review
Chapter Assessment
CDN
What is CDN?
Origin Server vs. Edge Server
CDN Architecture
Push CDN vs. Pull CDN
Flashcards Review
Chapter Assessment
Data Partitioning
Introduction to Data Partitioning
Partitioning Methods
Data Sharding Techniques
Benefits of Data Partitioning
Common Problems Associated with Data Partitioning
Flashcards Review
Chapter Assessment
Redundancy and Replication
What is Redundancy?
What is Replication?
Replication Methods
Data Backup vs. Disaster Recovery
Flashcards Review
Chapter Assessment
CAP & PACELC Theorems
Introduction to CAP Theorem
Components of CAP Theorem
Trade-offs in CAP Theorem
Examples of CAP Theorem in Practice
Beyond CAP Theorem
System Design Trade-offs in Interviews
Flashcards Review
Chapter Assessment
Databases (SQL vs. NoSQL)
Introduction to Databases
SQL Databases
NoSQL Databases
SQL vs. NoSQL
ACID vs BASE Properties
Real-World Examples and Case Studies
SQL Normalization and Denormalization
In-Memory Database vs. On-Disk Database
Data Replication vs. Data Mirroring
Database Federation
Flashcards Review
Chapter Assessment
Indexes
What are Indexes?
How a B-Tree Index Works
Types of Indexes
B-Tree vs. LSM Tree
Indexes in Distributed Systems
Flashcards Review
Chapter Assessment
Bloom Filters
Introduction to Bloom Filters
Benefits & Limitations of Bloom Filters
Variants and Extensions of Bloom Filters
Applications of Bloom Filters
Flashcards Review
Chapter Assessment
Quorum
Why Quorum?
What is Quorum?
Flashcards Review
Chapter Assessment
Leader and Follower
What is Leader and Follower Pattern?
Flashcards Review
Chapter Assessment
Heartbeat
What is Heartbeat?
Flashcards Review
Chapter Assessment
Checksum
What is Checksum?
Uses of Checksum
Flashcards Review
Chapter Assessment
Distributed Messaging System
Introduction to Messaging System
Introduction to Kafka
Messaging patterns
Popular Messaging Queue Systems
RabbitMQ vs. Kafka vs. ActiveMQ
Scalability and Performance
Flashcards Review
Chapter Assessment
Distributed File Systems
What is a Distributed File System?
Architecture of a Distributed File System
Key Components of a DFS
Flashcards Review
Chapter Assessment
Security
What is Security and Privacy?
What is Authentication?
What is Authorization?
Authentication vs. Authorization
OAuth vs. JWT for Authentication
What is Encryption?
What are DDoS Attacks?
Flashcards Review
Chapter Assessment
Misc Concepts
Batch Processing vs. Stream Processing
XML vs. JSON
Synchronous vs. Asynchronous Communication
Push vs. Pull Notification Systems
Microservices vs. Serverless Architecture
Message Queues vs. Service Bus
Stateful vs. Stateless Architecture
Event-Driven vs. Polling Architecture
Flashcards Review
Chapter Assessment
Quiz - System Design Fundamentals
Quiz
How to Approach a System Design Interview
System Design Interviews - A step by step guide
Functional vs. Non-functional Requirements
What are Back-of-the-Envelope Estimations?
Things to Avoid During System Design Interview
System Design Master Template
System Design Master Template
Quiz
Designing a URL Shortening Service like TinyURL
Designing a URL Shortening Service like TinyURL
Quiz - Designing URL Shortner
Designing Pastebin
Designing Pastebin
Quiz - Designing Pastebin
Designing Instagram
Designing Instagram
Quiz - Designing Instagram
Designing Dropbox
Designing Dropbox
Quiz - Designing Dropbox
Designing Facebook Messenger
Designing Facebook Messenger
Quiz - Designing Facebook Messenger
Designing Twitter
Designing Twitter
Quiz - Designing Twitter
Designing Youtube or Netflix
Designing Youtube or Netflix
Quiz - Designing Youtube
Designing Typeahead Suggestion
Designing Typeahead Suggestion
Quiz - Designing Typeahead Suggestion
Designing an API Rate Limiter
Designing an API Rate Limiter
Quiz - Designing an API Rate Limiter
Designing Twitter Search
Designing Twitter Search
Quiz - Designing Twitter Search
Designing a Web Crawler
Designing a Web Crawler
Quiz - Designing a Web Crawler
Designing Facebook’s Newsfeed
Designing Facebook’s Newsfeed
Quiz - Designing Facebook’s Newsfeed
Designing Yelp or Nearby Friends
Designing Yelp or Nearby Friends
Quiz - Designing Yelp or Nearby Friends
Designing Uber backend
Designing Uber backend
Quiz - Designing Uber backend
Designing Ticketmaster
Designing Ticketmaster
Quiz - Designing Ticketmaster
Dynamo: How to design a key value store?
Dynamo: Introduction
High-Level Architecture
Data Partitioning
Replication
Vector Clocks and Conflicting Data
The Life of Dynamo’s put() & get() Operations
Anti-entropy Through Merkle Trees
Gossip Protocol
Dynamo Characteristics and Criticism
Summary: Dynamo
Quiz: Dynamo
Mock Interview: Dynamo
Designing YouTube Likes Counter (medium)
YouTube Likes Counter
Quiz
Cassandra: How to Design a Wide-column NoSQL Database?
Cassandra: Introduction
High-level Architecture
Replication
Cassandra Consistency Levels
Gossiper
Anatomy of Cassandra's Write Operation
Anatomy of Cassandra's Read Operation
Compaction
Tombstones
Summary: Cassandra
Quiz: Cassandra
Mock Interview: Cassandra
Kafka: How to Design a Distributed Messaging System?
Messaging Systems: Introduction
Kafka: Introduction
High-level Architecture
Kafka: Deep Dive
Consumer Groups
Kafka Workflow
Role of ZooKeeper
Controller Broker
Kafka Delivery Semantics
Kafka Characteristics
Summary: Kafka
Quiz: Kafka
Mock Interview: Kafka
Chubby: How to Design a Distributed Locking Service?
Chubby: Introduction
High-level Architecture
Design Rationale
How Chubby Works
File, Directories, and Handles
Locks, Sequencers, and Lock-delays
Sessions and Events
Master Election and Chubby Events
Caching
Database
Scaling Chubby
Summary: Chubby
Quiz: Chubby
Mock Interview: Chubby
HDFS: How to Design File Storage System?
Hadoop Distributed File System: Introduction
High-level Architecture
Deep Dive
Anatomy of a Read Operation
Anatomy of a Write Operation
Data Integrity & Caching
Fault Tolerance
HDFS High Availability (HA)
HDFS Characteristics
Summary: HDFS
Quiz: HDFS
Mock Interview: HDFS
GFS: How to Design a Distributed File System Storage?
Google File System: Introduction
High-level Architecture
Single Master and Large Chunk Size
Metadata
Master Operations
Anatomy of a Read Operation
Anatomy of a Write Operation
Anatomy of an Append Operation
GFS Consistency Model and Snapshotting
Fault Tolerance, High Availability, and Data Integrity
Garbage Collection
Criticism on GFS
Summary: GFS
Quiz: GFS
Mock Interview: GFS
BigTable: How to Design a Wide Column Storage System?
BigTable: Introduction
BigTable Data Model
System APIs
Partitioning and High-level Architecture
SSTable
GFS and Chubby
Bigtable Components
Working with Tablets
The Life of BigTable's Read & Write Operations
Fault Tolerance and Compaction
BigTable Refinements
BigTable Characteristics
Summary: BigTable
Quiz: BigTable
Mock Interview: BigTable
Designing Reddit (medium)
Design Reddit
Quiz
Designing Notification Service (medium)
Designing a Notification System
Quiz
Design Google Calendar (medium)
Design Google calendar (Medium)
Quiz
Design a Recommendation System (medium)
Design a Recommendation System for Netflix
Quiz
Designing Gmail (medium)
Design Gmail
Quiz
Designing Google News (medium)
Design Google News, a Global News Aggregator System (Medium)
Quiz
Designing Unique ID Generator (medium)
Design Unique ID Generator (Easy)
Quiz
Designing Code Judging System (medium)
Design Code Judging System like LeetCode (Medium)
Quiz
Designing Payment System (hard)
Design Payment System
Quiz
Designing Flash Sale System (hard)
Design a Flash Sale for an E-commerce Site (Hard)
Quiz
Designing Reminder Alert System (hard)
Design a Reminder Alert System
Quiz
System Design Patterns
Introduction: System Design Patterns
1. Bloom Filters
2. Consistent Hashing
3. Quorum
4. Leader and Follower
5. Write-ahead Log
6. Segmented Log
7. High-Water Mark
8. Lease
9. Heartbeat
10. Gossip Protocol
11. Phi Accrual Failure Detection
12. Split Brain
13. Fencing
14. Checksum
15. Vector Clocks
16. CAP Theorem
17. PACELC Theorem
18. Hinted Handoff
19. Read Repair
20. Merkle Trees
Quiz
Strong vs Eventual Consistency
consistency
strong consistency
eventual consistency
replication
+3
You update your profile picture, and the page reloads showing the old one.
Nothing is broken. Your write went to one machine. Your read came back from another. That second machine had not received the change yet.
Almost every serious system keeps copies of its data on several machines. Keeping copies is called replication, and each copy is a replica. Redundancy and Replication explains why the copies exist. This lesson is about the question the copies create. After a write, what does the next read see?
There are two answers, and they cost different things.
- Strong consistency: every read returns the most recent write, always. To promise that, the system makes the write wait.
- Eventual consistency: the read is answered at once, and it may briefly return the old value. The copies catch up shortly after.
Strong Consistency
A system is strongly consistent when a finished write is visible to every later read. It does not matter which client reads or which replica answers.
The mechanism is simple. The write goes to the primary, the one node that accepts writes. The primary sends the change to its replicas. It does not confirm the write until enough replicas report that they have it. Only then does the client hear "OK". This is synchronous replication: the write waits for the copying to happen.
No replica is behind at the moment the write completes. So no read can return old data.
What it gives you.
- Reads are always correct. No user ever sees an old value.
- Simple application code. You never handle a stale read, meaning a read that returns an older value.
What it costs you.
- Slow writes. The write waits for the slowest replica it needs, plus the network. Replicas in the same data centre add about a millisecond. A replica on another continent adds the full round trip. No engineering removes that delay, because it comes from the distance itself.
- Refused writes. If a needed replica is unreachable, the system faces a choice. Accept the write and break the promise, or refuse the write. A strongly consistent system refuses.
The classic case for it is money. You withdraw 100 from an account holding 500. Every later read, anywhere, must say 400. A window where some machine still says 500 is a window where the money can be spent twice.
Refusing writes is correct behaviour for a bank balance. It is terrible behaviour for a photo feed. That difference is why this is a decision, not a default.
Eventual Consistency
A system is eventually consistent when its copies converge once writes stop. Converge means they all end up holding the same value. The promise is convergence, not timing.
The mechanism is the same replication with the waiting removed. The write goes to one node. That node confirms it at once. The change travels to the other replicas in the background. This is asynchronous replication: the copying happens after the confirmation. A read that reaches a replica before the change does returns the old value.
What it gives you.
- Fast writes. A write is as fast as one machine.
- Availability. The system keeps accepting reads and writes while replicas are unreachable, because no node waits on another.
What it costs you.
- A stale window. For a short time, two users can see different data.
- Careful application code. Every reader must behave correctly when a value is briefly old.
DNS, the system that maps domain names to server addresses, works this way. Change a domain's address, and some resolvers serve the old address for minutes or hours. Nobody calls DNS broken. The staleness is known, measured, and planned for.
How Long Is Eventually?
Replication lag is the delay between a write on one node and its arrival at the other copies. This number decides whether the trade is acceptable, and most explanations skip it.
Inside one data centre, lag is normally a few milliseconds. Across regions, it is tens to low hundreds of milliseconds. For most data, the window closes before the user can even reload the page.
The window is not always small. Lag grows under heavy write load, while a restarted replica catches up, and when a network link degrades. A replica can fall minutes behind. If lag affects correctness anywhere in your design, monitor it, and say that in the interview.
Read Your Own Writes
Here is the practical middle ground, and the reason eventual consistency is usable at all.
Users rarely notice that other people see stale data. They notice when they see it themselves. You post a comment, the page refreshes, and your comment is missing. The system is working exactly as designed, and it still looks like a bug.
The fix is narrow and cheap. For a short time after a user writes, serve that user's reads from the primary. Everyone else keeps reading from replicas. This is called read-your-own-writes consistency.
You keep cheap replica reads for almost all traffic. You remove the one staleness a user can actually see. The cost is a small piece of routing logic and slightly more load on the primary.
Two more named levels sit between the extremes. Causal consistency keeps dependent operations in order, so a reply never appears before the message it answers. Bounded staleness puts a hard limit on how old a read may be, in seconds or in versions. Some stores, including Azure Cosmos DB and MongoDB, let you pick a level per operation.
One Page, Several Answers
The common mistake is choosing one model for a whole system. Real designs choose per piece of data.
Look at one shopping page. The account balance must be strong, because a wrong number is a real problem. The stock count should be strong too, since selling the last item twice costs money. The view counter can be eventual, because nobody notices a few seconds of delay there. The recommendations can be minutes old.
That is four answers on one page. Name the data, not the system. "Balance reads go to the primary and are strong. Everything else is served from replicas."
Comparing the Two
| Strong consistency | Eventual consistency | |
|---|---|---|
| After a write | Every read returns the new value | A read may briefly return the old value |
| Write speed | Waits for replicas to confirm | One node confirms at once |
| A replica is unreachable | May refuse writes | Keeps accepting reads and writes |
| Copying style | Synchronous | Asynchronous, in the background |
| Typical stores | Spanner, etcd, one-primary relational setups | Cassandra, DynamoDB, DNS, most caches |
| Fits | Money, stock, bookings | Feeds, counters, recommendations |
Treat the two models as the ends of a range, not as two boxes. Most real systems sit between the ends, on purpose.
Choosing
- The data counts something that must be exact: money, stock, seats, bookings. Choose strong.
- The data is content or a casual count: feeds, likes, views, recommendations. Choose eventual.
- A user will read back their own change: choose eventual, plus read-your-own-writes.
- Replicas live in several regions and writes must stay fast: choose eventual, because strong pays the round trip on every write.
- You cannot decide yet: start strong, and relax specific reads when measurements show the need.
Three glossary lessons hold the theory behind this choice. CAP Theorem explains the forced choice during a network partition, a failure that cuts machines off from each other. PACELC Theorem extends it to normal operation, where every request trades latency against consistency. Quorum is the tuning tool: it sets how many replicas must confirm each read and write. And how the writing nodes themselves are arranged is its own trade-off, covered in Primary-Replica vs Peer-to-Peer Replication.
💡 In the interview: do not answer "strong" or "eventual" for the whole system. Split it. Name the one or two pieces of data that cannot be stale, and send those reads to the primary. Put everything else on replicas. Then add read-your-own-writes for each user's own data, because that is the only staleness a user can see. Expect the follow-up "how stale can a replica get?". Answer with numbers: a few milliseconds inside a data centre, and minutes when a replica is catching up, which is why lag is monitored.
Key takeaway: strong consistency promises that every read returns the newest write. The cost is writes that wait for replicas, and writes that are refused when replicas are unreachable. Eventual consistency confirms at once and lets the copies converge in the background. The gain is speed and availability, and the cost is a short window where two readers can disagree. Neither is better. Decide per piece of data, add read-your-own-writes so users always see their own changes, and know your replication lag.
Discussion
On This Page