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
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
ACID vs BASE Properties
acid
databases
cap theorem
consistency
+3
A customer transfers 100 dollars to a friend. The bank's system takes the money from the customer's account, and then crashes before adding it to the friend's account. The 100 dollars has disappeared. No bank can accept that.
Databases have two well-known approaches to problems like this, and they make different trade-offs.
- ACID keeps every transaction strictly correct, even if the system must wait or refuse requests to do it.
- BASE keeps the system answering, even if some answers are briefly out of date.
This lesson explains both, clears up a common confusion about the word "consistency", and shows how to choose.
ACID
A transaction is a unit of work with several steps that must count as one. A money transfer is the standard example. Step one takes 100 dollars from account A. Step two adds 100 dollars to account B.
ACID is a set of four promises that a database makes about transactions: Atomicity, Consistency, Isolation, and Durability.
Atomicity: All or Nothing
The transaction happens completely, or not at all. If step two fails, the database undoes step one. This undo is called a rollback. So money is never taken without being delivered.
For example, account A holds 500 dollars and account B holds 200 dollars. If the transfer fails halfway, the rollback returns both accounts to 500 and 200.
Consistency: The Rules Always Hold
Every database has rules about its data. For example, a balance may not go below zero, and every order must belong to a real customer. Consistency means each transaction moves the data from one valid state to another valid state. In the transfer, the total across both accounts is 700 dollars before and after.
Isolation: Transactions Do Not Interfere
Many transactions run at the same time. Isolation means they do not interfere with each other's unfinished work. For example, a reader never sees a stock count that another transaction has changed but not yet committed.
Databases offer different isolation levels. At the strictest level, called serializable, transactions behave as if they ran one after another. Many databases use a weaker level by default, because it is faster. The weaker level allows some rare problems between transactions.
Durability: Committed Means Saved
Once the database confirms a transaction, the change survives a crash or a power failure. Databases usually do this by writing the change to a log on disk before confirming it. So if a messaging app says a message was sent, the message is stored, even if the server loses power a moment later.
Relational databases like PostgreSQL and MySQL are built around these promises, which is why they are common for financial ledgers.
The Cost of ACID
Keeping these promises takes work. The database must lock data and make some transactions wait. When the data is spread across several machines, the machines must also coordinate before confirming a transaction, which is slower and harder to keep available. BASE removes much of that cost.
BASE
BASE describes how many NoSQL and distributed databases behave. It stands for Basically Available, Soft state, and Eventually consistent.
Basically Available: The System Answers
Even during heavy load or a partial failure, the system tries to give a response, though the data may not be fully up to date. For example, during a big sale, an online store keeps accepting orders, while the displayed stock counts are a little behind.
Soft State: Data Can Change Without New Input
Updates spread between the copies of the data in the background. So the state of a copy can change over time, even when no new request arrives, as older updates reach it.
Eventually Consistent: The Copies Agree Over Time
If no new updates are made, all copies of the data eventually become identical. There is no fixed promise about how long that takes. It is often less than a second, but it can be longer during failures. The Strong vs Eventual Consistency lesson explains what this waiting means for readers.
For example, a store has three copies of a stock count. A sale changes the count from 10 to 9 on copy A. For about 300 ms, copies B and C still show 10. A reader who reaches copy B during that time sees the old value. Then the update arrives, and all three copies show 9.
One Word, Two Meanings
The word "consistency" causes a common mistake. The C in ACID and the C in the CAP theorem are not the same thing.
- The C in ACID is about one database following its rules. Every transaction leaves the data valid: no negative balances, and no order without a customer. A single machine can make this promise by itself.
- The C in CAP is about copies agreeing. Every read returns the newest write, no matter which copy answers. This promise only matters when the data is stored on more than one machine.
When people say a BASE database "gives up consistency", they mean the CAP kind. Copies may briefly disagree with each other. They do not mean the database breaks its data rules.
What Happens During a Network Failure
The CAP theorem explains why both styles exist. It names three properties: Consistency, Availability, and Partition tolerance.
A partition is a network failure that cuts some machines off from others. Partitions happen whether you plan for them or not. So a distributed system must handle them, and each system must choose how to behave during one. While the machines cannot reach each other, a system does one of two things:
- A system that favors consistency refuses. The user sees an error or a delay, but never an outdated value.
- A system that favors availability answers. The user always gets a response, but it may be outdated.
Traditional ACID databases usually favor consistency, and BASE databases usually favor availability. The CAP Theorem lesson explains this in depth.
ACID vs. BASE
| ACID | BASE | |
|---|---|---|
| Priority | Correctness | Availability |
| After a write | Everyone sees it immediately | Everyone sees it eventually |
| During a network partition | May refuse to answer | Answers with the data it has |
| Who resolves disagreements | The database | The application |
| Typical databases | Relational databases | Many NoSQL and distributed databases |
| Good fit | Money, stock counts, bookings | Likes, view counts, feeds, shopping carts |
The row people often miss is "who resolves disagreements". In a BASE database, copies can disagree, and something must decide which value wins. That job moves into your application. Common approaches are:
- Last write wins: keep the value with the newest timestamp, and discard the others.
- Version vectors: track which updates each copy has seen, to detect conflicts.
- Merge rules: combine conflicting values in a way that fits the data. For example, merge two versions of a shopping cart by keeping the items from both.
Choosing Between Them
- Money, stock that must not be oversold, or bookings: use ACID transactions. A wrong value is worse than a slow or failed request.
- Likes, view counts, feeds, and similar data: BASE is usually fine. A value that is briefly out of date does no harm, and the system stays available.
- Most real systems use both. For example, payments in a relational database, and activity feeds in a distributed NoSQL database.
Using This in an Interview
If you say you will use a BASE database, expect a follow-up question: "What happens when two copies disagree?" Have a concrete answer, like last write wins, version vectors, or a merge rule for that exact data.
Also keep the two meanings of consistency separate. BASE relaxes the CAP kind, which is agreement between copies. It does not mean the data stops following its rules. Mixing up the two is a mistake that interviewers notice quickly.
Key Takeaways
- ACID is four promises about transactions: atomicity (all or nothing), consistency (rules always hold), isolation (no interference), and durability (committed means saved).
- Durability means a committed transaction stays saved, even after a crash or power failure.
- BASE means Basically Available, Soft state, and Eventually consistent.
- Eventual consistency promises that if no new updates are made, all copies eventually become identical.
- The C in ACID means following data rules. The C in CAP means copies agree on the newest value.
- During a network partition, a system either refuses to answer or answers with possibly outdated data.
- In a BASE database, the application must resolve disagreements between copies.
ACID protects correctness, and BASE protects availability. The next lesson, Strong vs Eventual Consistency, looks closely at what readers see in each case.
Practice Questions
Try each question first, then open the answer.
1. Account A holds 500 dollars, and account B holds 200 dollars. A transfer of 100 dollars takes the money from A, and then the server crashes before adding it to B. With atomicity, what are the balances after the database recovers?
<details> <summary>Show answer</summary>A holds 500 dollars, and B holds 200 dollars. The transaction did not finish, so atomicity requires a rollback. The debit from A is undone. The total is still 700 dollars, so no money was lost. The customer can then try the transfer again.
</details>2. One item is left in stock. Two customers try to buy it at the same moment, and both transactions read "stock = 1". Which ACID property prevents both purchases from succeeding?
<details> <summary>Show answer</summary>Isolation. With a strict enough isolation level, or with a lock on the stock row, the two transactions cannot both update the stock count. One purchase succeeds and sets the stock to 0. The other transaction then sees 0, or fails and must retry, so the item is not sold twice.
</details>3. A messaging app shows "message sent" after the database confirms the transaction. One second later, the server loses power. After the restart, is the message still stored?
<details> <summary>Show answer</summary>Yes, because of durability. Once a transaction is committed, the change must survive crashes and power failures. The database wrote the change to its log on disk before confirming it, so it can recover the message after the restart.
</details>4. A BASE database keeps three copies of a like count. A new like updates copy A at time 0, and copies B and C receive the update at about 300 ms. A reader reaches copy B at 100 ms. What does the reader see, and what happens if there are no more likes?
<details> <summary>Show answer</summary>The reader sees the old count. At 100 ms, copy B has not received the update yet. This is eventual consistency. If no new updates arrive, all three copies hold the same count by about 300 ms. For a like count, this short delay does no harm.
</details>5. During a network partition, a shopping cart service cannot reach some copies of the data. Should it refuse to update carts, or accept updates and resolve conflicts later? Would a bank transfer be different?
<details> <summary>Show answer</summary>The cart service should accept updates, and the bank transfer should not. For a shopping cart, staying available matters most, and conflicts can be merged later, for example by keeping the items from both versions. For a bank transfer, an outdated or conflicting balance is not acceptable. So the bank should refuse or delay the transfer until the copies can agree.
</details>Discussion
On This Page