System Design
Learn System Design
Introduction to System Design
How to Learn System Design?
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
System Design Trade-offs
Importance of Discussing Trade-offs
Strong vs Eventual Consistency
Latency vs Throughput
ACID vs BASE Properties in Databases
Read-Through vs Write-Through Cache
Batch Processing vs Stream Processing
Load Balancer vs. API Gateway
API Gateway vs Direct Service Exposure
Proxy vs. Reverse Proxy
API Gateway vs. Reverse Proxy
SQL vs. NoSQL
Primary-Replica vs Peer-to-Peer Replication
Data Compression vs Data Deduplication
Server-Side Caching vs Client-Side Caching
REST vs RPC
Polling vs. Long-Polling vs. WebSockets vs. Webhooks
CDN Usage vs Direct Server Serving
Serverless Architecture vs Traditional Server-based
Stateful vs Stateless Architecture
Hybrid Cloud Storage vs All-Cloud Storage
Token Bucket vs Leaky Bucket
Read Heavy vs Write Heavy System
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
Fault Tolerance vs. High Availability
fault tolerance
high availability
data integrity
load balancing
A bank's payment system and a video streaming site each lose a server at the same moment.
At the bank, nothing visible happens. Payments keep going through, and no payment is lost. At the streaming site, some videos stop loading for about 20 seconds. Then they start again.
Both systems worked exactly as they were designed. They were built to make two different promises. This lesson explains what each promise means, how each one is built, and how to choose between them.
Two Different Promises
Fault tolerance is the ability of a system to keep functioning correctly, without interruption, when some of its parts fail. Users do not notice the failure, and no data is lost.
High availability is the ability of a system to stay operational and accessible for a very high percentage of the time. When a part fails, there may be a short interruption. The system then recovers quickly, and downtime stays small.
In short, fault tolerance means users never notice a failure. High availability means users rarely notice one, and only for a short time.
Both promises use redundancy, which means keeping extra copies of important parts. The difference is how the copies are used, and what happens in the seconds after a failure.
How Fault Tolerance Works
A fault-tolerant system is designed so that a failure needs no recovery step that users can see. The copies are already doing the work when a part fails.
Active copies. Several copies of each part do the same work at the same time. When one copy fails, the others are already serving users. Nothing has to start, and nothing has to switch.
Synchronous replication. With synchronous replication, a write counts as complete only after it is saved on at least two machines. If one machine fails right after the write, the data still exists on another one. This is how fault-tolerant systems avoid losing data.
Voting. Some systems run the same calculation on three or more computers and compare the results. The system uses the majority answer. A computer that fails, or gives a wrong answer, is simply outvoted. Aircraft flight control systems work this way, and the quorum chapter explains the same idea for databases.
Redundant hardware. Single machines are built with spare parts inside them. Examples are two power supplies and two network connections. Another example is RAID, which stores data across several disks so that one disk can fail without data loss.
Automatic failover. When a part fails, the system moves work away from it immediately. No person has to act.
All of this costs more. Every part runs as two or three copies, all the time. Synchronous writes are slower, because each write waits for another machine. And the design is harder to build, test, and run.
How High Availability Works
A highly available system also has copies. But it accepts a short pause while it detects a failure and recovers from it.
Redundancy and clustering. Services run as a cluster, which is a group of servers that work together as one system. If one server fails, the others in the cluster keep working.
Load balancing. A load balancer spreads requests across healthy servers. When health checks show that a server has failed, the load balancer stops sending it traffic.
Rapid recovery. A standby copy takes over after a failure. For a database, a replica is promoted to become the new primary. Detecting the failure and switching usually takes seconds, sometimes a minute or two.
Asynchronous replication. Many highly available databases use asynchronous replication. The primary confirms a write first and copies it to the replicas a moment later. Writes are faster, but if the primary fails before the copy arrives, the most recent writes can be lost.
High availability is usually described in nines. For example, 99.99 percent availability allows about 52.6 minutes of downtime per year. The Availability lesson explains the nines and failover in detail.
The main benefit is cost. High availability gives most of the protection for much less money and complexity. It balances cost against the level of availability that the product actually needs.
The Five Key Differences
1. Objective. Fault tolerance aims for continuous operation, so a failure never becomes visible to users. High availability aims for as much uptime as possible, with fast recovery when something fails.
2. Approach. Fault tolerance uses active copies, synchronous replication, and automatic failover, so there is nothing to recover. High availability uses redundancy, load balancing, and fast failover to a standby.
3. Downtime. Fault tolerance allows no downtime, even during a failure. High availability accepts brief interruptions, often seconds to a minute.
4. Cost and complexity. Fault tolerance is more expensive and more complex, because it needs full copies that are always active. High availability is more cost-effective.
5. Data integrity. Fault tolerance keeps all data safe, even during a failure. High availability puts uptime first, so a small amount of recent data can be lost in some failures.
| Fault tolerance | High availability | |
|---|---|---|
| Downtime during a failure | None | Brief, and accepted |
| Data loss | None | Possible for the most recent writes |
| Main tools | Active copies, synchronous replication, voting | Clusters, load balancing, fast failover |
| Cost | High | Balanced against the target |
| Typical use | Finance, healthcare, aviation | Online stores, streaming, most business apps |
Choosing Between Them
Choose fault tolerance when downtime or data loss can cause serious harm. This is why it belongs in critical systems in finance, healthcare, and aviation. A payment that disappears, a heart monitor that pauses, or a flight computer that stops for 20 seconds is not acceptable.
Choose high availability when a short interruption is acceptable and cost matters. An online store that fails over in 30 seconds loses a few page loads. Users retry, and the business continues.
Two questions help decide.
- Can a few seconds of downtime cause serious harm or a large loss?
- Is losing the last few seconds of writes unacceptable?
If the answer to the first question is yes, the part needs fault tolerance. If only the second answer is yes, protect the data with synchronous replication, and use high availability for the rest.
Most systems use both, for different parts. In an online store, the payment records need fault tolerance for the data, with synchronous replication. The product catalog needs high availability. The recommendations service can simply degrade gracefully when it fails. Choosing per part gives strong protection where it matters, without paying for it everywhere.
Key Takeaways
- Fault tolerance keeps a system functioning correctly, without interruption, when parts fail. There is no downtime and no data loss.
- High availability keeps a system operational for a very high percentage of the time. It accepts brief interruptions and recovers quickly.
- Fault tolerance uses active copies, synchronous replication, voting, and automatic failover. It costs more and is more complex.
- High availability uses clusters, load balancing, and fast failover. It is more cost-effective, but recent writes can be lost in some failures.
- Choose fault tolerance for critical systems in finance, healthcare, and aviation. Choose high availability when short interruptions are acceptable.
- Real systems mix both and choose for each part.
These two promises are not two levels of the same thing. They are different trade-offs between cost, downtime, and data safety. That completes this chapter. Next is a Flashcards Review of the key terms, followed by the Chapter Assessment.
Practice Questions
Try each question first, then open the answer.
1. A hospital runs a system that shows live patient heart data to nurses. An online bookstore runs its product pages. Which system needs fault tolerance, and which one needs high availability?
<details> <summary>Show answer</summary>The patient system needs fault tolerance, and the bookstore needs high availability. If the heart data pauses for 20 seconds, a nurse could miss a dangerous change, so any downtime can cause serious harm. If the bookstore pauses for 20 seconds, a few customers reload the page. A short interruption is acceptable there, and high availability costs much less.
</details>2. A database uses asynchronous replication, and its replica is about 3 seconds behind. The primary confirms 50 orders, then crashes 2 seconds later. The replica becomes the new primary. What happens to those orders, and what would prevent it?
<details> <summary>Show answer</summary>Those 50 orders can be lost. The primary confirmed them, but the replica was 3 seconds behind, so they had not been copied yet. Synchronous replication prevents this, because a write is confirmed only after a second machine has saved it. The cost is slower writes.
</details>3. A highly available service takes 15 seconds to detect a failure and 15 seconds to switch to a standby. It fails 4 times in a 30-day month. How much downtime does it have, and does it meet a 99.9 percent target?
<details> <summary>Show answer</summary>2 minutes of downtime, so it meets the target. Each failure causes 15 + 15 = 30 seconds of downtime. Four failures give 4 x 30 = 120 seconds, which is 2 minutes. A 99.9 percent target allows 43.2 minutes in a 30-day month. This service even meets 99.99 percent, which allows 4.32 minutes.
</details>4. An aircraft uses three flight computers that vote on every result. Why not use one active computer and one standby computer instead?
<details> <summary>Show answer</summary>A standby needs time to detect the failure and take over, and that pause is not acceptable in flight. With voting, all three computers work at the same time. If one fails, the other two are already producing the answer. Voting also catches a computer that gives a wrong answer without crashing, because the other two outvote it.
</details>5. A new company wants fault tolerance for every part of its app, including search and recommendations. What is the problem with this plan, and what would you suggest?
<details> <summary>Show answer</summary>It pays for far more protection than most parts need. Fault tolerance needs full active copies, slower synchronous writes, and a more complex design everywhere. A better plan is to choose for each part. Use fault tolerance for data that must never be lost, like payments. Use high availability for the rest, and let features like recommendations degrade gracefully.
</details>Discussion
On This Page