System Design

Learn 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

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

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

Introduction to DNS

DNS Resolution Process

DNS Load Balancing and High Availability

Flashcards Review

Chapter Assessment

What is a Proxy Server?

Uses of Proxies

VPN vs. Proxy Server

Flashcards Review

Chapter Assessment

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

Introduction to API Gateway

Usage of API gateway

Advantages and disadvantages of using API gateway

Flashcards Review

Chapter Assessment

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

What Is Rate Limiting

Rate Limiting Algorithms

Distributed Rate Limiting

Rate Limiting in Practice

Flashcards Review

Chapter Assessment

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

What is CDN?

Origin Server vs. Edge Server

CDN Architecture

Push CDN vs. Pull CDN

Flashcards Review

Chapter Assessment

Introduction to Data Partitioning

Partitioning Methods

Data Sharding Techniques

Benefits of Data Partitioning

Common Problems Associated with Data Partitioning

Flashcards Review

Chapter Assessment

What is Redundancy?

What is Replication?

Replication Methods

Data Backup vs. Disaster Recovery

Flashcards Review

Chapter Assessment

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

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

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

Introduction to Bloom Filters

Benefits & Limitations of Bloom Filters

Variants and Extensions of Bloom Filters

Applications of Bloom Filters

Flashcards Review

Chapter Assessment

Why Quorum?

What is Quorum?

Flashcards Review

Chapter Assessment

What is Leader and Follower Pattern?

Flashcards Review

Chapter Assessment

What is Heartbeat?

Flashcards Review

Chapter Assessment

What is Checksum?

Uses of Checksum

Flashcards Review

Chapter Assessment

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

What is a Distributed File System?

Architecture of a Distributed File System

Key Components of a DFS

Flashcards Review

Chapter Assessment

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

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

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

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

Quiz

Designing a URL Shortening Service like TinyURL

Quiz - Designing URL Shortner

Designing Pastebin

Quiz - Designing Pastebin

Designing Instagram

Quiz - Designing Instagram

Designing Dropbox

Quiz - Designing Dropbox

Designing Facebook Messenger

Quiz - Designing Facebook Messenger

Designing Twitter

Quiz - Designing Twitter

Designing Youtube or Netflix

Quiz - Designing Youtube

Designing Typeahead Suggestion

Quiz - Designing Typeahead Suggestion

Designing an API Rate Limiter

Quiz - Designing an API Rate Limiter

Designing Twitter Search

Quiz - Designing Twitter Search

Designing a Web Crawler

Quiz - Designing a Web Crawler

Designing Facebook’s Newsfeed

Quiz - Designing Facebook’s Newsfeed

Designing Yelp or Nearby Friends

Quiz - Designing Yelp or Nearby Friends

Designing Uber backend

Quiz - Designing Uber backend

Designing Ticketmaster

Quiz - Designing Ticketmaster

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

YouTube Likes Counter

Quiz

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

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: 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

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

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: 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

Design Reddit

Quiz

Designing a Notification System

Quiz

Design Google calendar (Medium)

Quiz

Design a Recommendation System for Netflix

Quiz

Design Gmail

Quiz

Design Google News, a Global News Aggregator System (Medium)

Quiz

Design Unique ID Generator (Easy)

Quiz

Design Code Judging System like LeetCode (Medium)

Quiz

Design Payment System

Quiz

Design a Flash Sale for an E-commerce Site (Hard)

Quiz

Design a Reminder Alert System

Quiz

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 vs. High Availability

fault tolerance

high availability

data integrity

load balancing

hard
·
11 min
·Updated Sep 2026·Credit: System Design Fundamentals

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.

Image
Under fault tolerance the failure is absorbed and users see nothing, while under high availability there is a short interruption before service returns

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.

Image
Synchronous replication waits for a replica before confirming a write, so a crash loses nothing, while asynchronous replication confirms first and can lose recent writes

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 toleranceHigh availability
Downtime during a failureNoneBrief, and accepted
Data lossNonePossible for the most recent writes
Main toolsActive copies, synchronous replication, votingClusters, load balancing, fast failover
CostHighBalanced against the target
Typical useFinance, healthcare, aviationOnline 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.

  1. Can a few seconds of downtime cause serious harm or a large loss?
  2. 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.

Image
Two questions decide the choice: whether seconds of downtime cause serious harm, and whether losing recent writes is unacceptable

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
Have a question or insight about this topic? Share it with the community.
Reading Progress
0%

On This Page