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
Latency vs Throughput
latency
throughput
consistency models
availability
+2
A food delivery app works well at 4 PM. Each menu page opens in about 150 ms. At 8 PM, ten times more people open the app to order dinner. The same page now takes 3 seconds to open.
The servers did not become slower. Each request still needs the same amount of work. What changed is how many requests arrived at the same time.
This shows that "fast" can mean two different things. It can mean that one request finishes quickly. It can also mean the system finishes many requests every second. These are two different numbers, called latency and throughput. This lesson explains both numbers, how they are connected, and when improving one costs the other.
Two Different Numbers
Latency is the time one request takes, from the moment it is sent to the moment the response arrives. It is measured in milliseconds (ms). Lower latency is better.
The latency of one request usually has three parts:
- Network time. The request and response travel between the user and the server.
- Waiting time. The request waits in a queue until a server is free to work on it.
- Processing time. The server does the actual work, like reading from a database and building the response.
Throughput is the amount of work a system completes in a unit of time. For web systems, it is usually counted as requests per second (RPS), also called queries per second (QPS). Higher throughput is better.
A supermarket checkout shows the difference. Latency is how long one customer spends at the checkout. Throughput is how many customers the store serves in one hour.
In short: latency is about one request, and throughput is about all the requests together.
They Are Separate Numbers
Latency and throughput are not opposites. A system can be good at one and bad at the other. All four combinations exist.
| Low throughput | High throughput | |
|---|---|---|
| Low latency | One fast server, handling one request at a time | The goal, and it usually costs more money |
| High latency | An overloaded system, which is the failure case | A batch job that processes a billion records over six hours |
The batch job is a useful example. Nobody waits for a single record, so latency does not matter much. But the job processes a huge number of records, so its throughput is very high.
Concurrency Connects Them
Concurrency is the number of requests being worked on at the same time.
Suppose one worker takes 100 ms to finish a request. It can finish 10 requests per second. Now add nine more workers, for ten in total. Together they finish 100 requests per second. But each request still takes 100 ms.
Throughput became ten times higher. Latency did not change. The extra throughput came from more concurrency.
This relationship is called Little's Law:
concurrency = throughput x latency
Little's Law turns capacity questions into simple arithmetic. Suppose a service must handle 2,000 requests per second, and each request takes 50 ms (0.05 seconds). Then 2,000 x 0.05 = 100 requests are being processed at any moment. This number tells you how many threads, connections, or servers you need.
Why They Trade Off Near Capacity
If the two numbers are separate, why do people call them a trade-off? The answer is capacity.
Utilization is the share of a server's capacity that is in use. At 50 percent utilization, the server is busy half of the time.
When a server is busy, a new request cannot start right away. It waits in a queue. That waiting time is added to its latency. The busier the server, the longer the queue, and the longer each request waits.
Here is a simple queueing model. Each request needs 10 ms of work on a free server, and any waiting time is added on top of that. The table shows the average latency at different utilization levels.
| Utilization | Average latency |
|---|---|
| 50 percent | 20 ms |
| 70 percent | 33 ms |
| 80 percent | 50 ms |
| 90 percent | 100 ms |
| 95 percent | 200 ms |
The work per request stays the same. Only the waiting time grows. In this model, latency equals the work time divided by the free share of capacity. At 90 percent utilization, only 10 percent is free, so 10 ms becomes 100 ms.
The pattern has three zones:
- Below about 70 percent, latency grows slowly.
- Between 70 and 90 percent, latency climbs quickly, so each extra unit of load is paid for with much more waiting.
- Above about 90 percent, latency rises very steeply, and almost no capacity is left to absorb a spike.
This is why teams usually run servers at 50 to 70 percent utilization, not at 95 percent. The spare capacity is not wasted. It keeps latency stable when traffic suddenly rises, like the dinner rush in the delivery app.
Batching Trades Latency for Throughput
Sometimes a team accepts higher latency on purpose, to get more throughput. The clearest example is batching. Batching means collecting many items and processing them together in one operation.
Suppose writing one record to a database takes 5 ms. Writing records one by one gives at most 200 records per second.
Now the service collects 100 records and writes them in one call, which takes 50 ms. That gives up to 2,000 records per second. Throughput became ten times higher.
But the first record in each batch must wait for the other 99 records to arrive. Its latency becomes much higher. So batching improves throughput, but it increases the latency of each item.
Buffering and queueing work in the same way. They raise throughput by making single items wait longer.
Measure Latency With Percentiles
An average latency can hide serious problems. Here is an example with 100 requests:
- 98 requests take 100 ms.
- 2 requests take 5,000 ms, because of retries or a slow database lock.
The average is (98 x 100 + 2 x 5,000) / 100 = 198 ms. That looks healthy. But two out of every hundred users wait five seconds, and those are the users who complain.
So real systems measure percentiles. To find them, sort all the request times from fastest to slowest.
- p50, also called the median: half of the requests take this long or less. It shows the typical experience.
- p95: 95 percent of the requests take this long or less. At most one request in 20 is slower.
- p99: 99 percent of the requests take this long or less. At most one request in 100 is slower. It shows the experience of the slowest users.
In the example, p50 is 100 ms and p95 is 100 ms. But p99 is 5,000 ms, and it shows the problem that the average hid.
Latency targets are usually written in a service level objective (SLO). An SLO is a promised performance target, like "p99 latency under 200 ms". "The API should be fast" is not a target, because nobody can measure it.
Slow Requests Add Up
The slow one percent matters more than it seems. One page load often makes many backend calls, not just one.
Suppose a page makes 100 backend calls, and each call has a 99 percent chance of being fast. The chance that all 100 calls are fast is 0.99 multiplied by itself 100 times, which is about 0.37. So about 63 percent of page loads include at least one slow call.
When one user action makes many calls, the slow requests affect most page loads. The Key Characteristics of Distributed Systems lesson covers these measurements together with availability and reliability.
How to Improve Latency
- Move the data closer to users. A CDN (content delivery network) is a network of servers placed near users. It shortens the distance that each request travels.
- Cache results. A cache is fast storage that keeps answers ready to use. A cache hit skips the slow work completely.
- Make fewer network round trips. Each network call in a sequence adds its own latency. Run independent calls in parallel, or combine related calls into one.
- Add indexes and tune queries. A slow query often reads far more data than it needs.
- Do less work while the user waits. Move work the user does not need right away, like sending an email, to a background job.
- Keep utilization moderate. Spare capacity keeps queues short, and it is often the cheapest fix.
How to Improve Throughput
- Add more servers. Put several servers behind a load balancer, so they share the requests.
- Increase concurrency. Use more workers, threads, or connections. Little's Law tells you how many you need.
- Batch the work. Group items to reduce the cost per item, and accept the extra waiting.
- Use a queue. Workers take jobs from a queue at their own speed, and the queue holds extra jobs during traffic spikes.
- Split the data. Sharding spreads data across several databases, so one database does not limit the whole system.
- Cache results. A cache also appears in this list, for the reason explained in the next section.
A Cache Improves Latency First
A cache appears in both lists, so which number does it improve?
A cache improves latency first. The answer is already computed and stored nearby, so the request skips the slow work. This is also why a CDN is mainly a latency tool.
Throughput improves as a result. On a cache hit, the backend does no work, so its capacity is free for other requests. For example, a video is processed once and then served from a cache to a thousand viewers. The backend does that work once, not a thousand times.
Most good techniques help both numbers. The techniques that truly trade one for the other add waiting on purpose, like batching, buffering, and queueing.
Latency and Throughput Side by Side
| Latency | Throughput | |
|---|---|---|
| Measures | The time for one request | The requests completed per second |
| Unit | Milliseconds | RPS or QPS |
| Better when | Lower | Higher |
| Report it as | A percentile, like p99 | Peak load, not only the average |
| Improved by | Closer data, caching, fewer round trips | More servers, concurrency, batching |
| Gets worse when | Utilization comes close to capacity | One slow step limits all the work |
Choosing What to Optimize
- A user is waiting for the response: optimize latency, and set the target as a percentile.
- Nobody waits for the result, like a nightly report: optimize throughput. Higher latency is acceptable here.
- The system is overloaded: add capacity or reject extra load first. Near full capacity, both numbers are bad.
- You are given a scale requirement: turn it into both numbers before you design anything.
Using These Numbers in an Interview
Start by turning the scale requirement into numbers. For example, "one million daily users, each loading the feed five times a day" means 5,000,000 requests per day. One day has 86,400 seconds, so the average is about 58 requests per second. The peak is usually several times higher.
Then use Little's Law to estimate how many requests the servers must process at the same time. State every latency target as a percentile, like "p99 under 200 ms".
Two follow-up questions are common:
- "How would you reduce latency?" Start with a cache or a CDN. Then add that the cache also takes load off the database, so throughput improves too.
- "Why not run the servers at 95 percent utilization?" Because queues grow very quickly near full capacity. A small rise in traffic would push latency far past the target.
Key Takeaways
- Latency is the time one request takes. Throughput is the number of requests completed per second.
- The two numbers are separate. Little's Law connects them: concurrency = throughput x latency.
- They trade off near full capacity, because requests wait in queues. Teams usually run servers at 50 to 70 percent utilization.
- Batching improves throughput, but it increases the latency of each item.
- Measure latency with percentiles like p50, p95, and p99. An average hides the slow requests that users notice.
- A cache improves latency first. Throughput improves too, because the backend skips the work.
Latency tells you how long one user waits, and throughput tells you how many users the system can serve. A good design states a target for both. The next lesson, Horizontal vs Vertical Scaling, explains the two basic ways to add capacity.
Practice Questions
Try each question first, then open the answer.
1. A service must handle 3,000 requests per second, and each request takes 40 ms. How many requests are being processed at the same time? If one server can process 20 requests at a time, how many servers are needed?
<details> <summary>Show answer</summary>120 requests at a time, which needs 6 servers at full capacity. By Little's Law, concurrency = 3,000 x 0.04 = 120. Each server handles 20 requests, so 120 / 20 = 6 servers. But 6 servers would run at 100 percent utilization. To stay near 70 percent, each server should handle only about 14 requests, which is 70 percent of 20. So you need 120 / 14, which is about 9 servers.
</details>2. Out of 1,000 requests, 980 take 50 ms, and 20 take 3,000 ms. What are the average latency, the p50, and the p99? Which number shows the problem?
<details> <summary>Show answer</summary>The average is 109 ms, p50 is 50 ms, and p99 is 3,000 ms. The average is (980 x 50 + 20 x 3,000) / 1,000 = (49,000 + 60,000) / 1,000 = 109 ms. When the requests are sorted, the 500th request takes 50 ms, so p50 is 50 ms. The 990th is one of the slow ones, so p99 is 3,000 ms. Only p99 shows that 2 percent of users wait three seconds.
</details>3. A logging service writes each event separately, and each write takes 4 ms. The team changes it to write 500 events in one call, which takes 50 ms. Events arrive at 1,000 per second. What happens to throughput and to latency?
<details> <summary>Show answer</summary>Throughput rises a lot, and latency per event also rises. Before, the service could write at most 1,000 / 4 = 250 events per second, which is too slow for 1,000 events arriving each second. After, one call writes 500 events in 50 ms, so it can write up to 10,000 events per second. But a batch of 500 takes half a second to fill. So the first event in each batch waits about 500 ms, plus the 50 ms write.
</details>4. To save money, a team wants to run its servers at 95 percent utilization instead of 60 percent. Each request needs 10 ms of work on a free server, with waiting time on top. Using the simple queueing model from this lesson, what happens to latency?
<details> <summary>Show answer</summary>Average latency rises from 25 ms to 200 ms. In the model, latency = work time / free share of capacity. At 60 percent, it is 10 / 0.4 = 25 ms. At 95 percent, it is 10 / 0.05 = 200 ms. Also, a small rise in traffic at 95 percent pushes the servers toward full capacity, where queues and latency grow without limit.
</details>5. A page makes 50 backend calls. Each call has a 99 percent chance of being fast. About what share of page loads includes at least one slow call?
<details> <summary>Show answer</summary>About 40 percent. The chance that all 50 calls are fast is 0.99 multiplied by itself 50 times, which is about 0.605. So the chance of at least one slow call is 1 - 0.605 = 0.395, which is about 40 percent. This is why the p99 of each backend service matters so much.
</details>Discussion
On This Page