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
availability
caching
+1
You tell the interviewer your design is fast. The interviewer asks: fast for one user, or fast for a million users at once?
Those are two different questions. Latency answers the first. Throughput answers the second. The skill this lesson teaches: know which number a requirement is really about, and what improving it costs the other.
The Two Definitions
Latency is how long one request takes, from the moment it is sent to the moment the response arrives. It is measured in milliseconds. Lower is better.
Throughput is how much work the system completes per unit of time. In an interview it is almost always requests per second (RPS), also called queries per second (QPS). Higher is better.
A supermarket shows the difference. Latency is how long one customer waits at the checkout. Throughput is how many customers the store serves per hour. The short version: latency is about one request, throughput is about all of them.
They Are Not Opposites
The two are separate axes, and all four combinations exist:
- Low latency, low throughput. One fast server, no parallel work. Quick requests, few at a time.
- High latency, high throughput. A batch pipeline that runs six hours over a billion records. Nobody waits, and the volume is enormous.
- Low latency, high throughput. The goal, and it costs money.
- High latency, low throughput. An overloaded system. The failure case.
The proof is concurrency, the number of requests being worked on at the same time. One worker that finishes a request in 100 ms completes 10 requests per second. Ten workers complete 100 per second, and each request still takes 100 ms. Throughput grew ten times. Latency did not move.
That relationship has a name. Little's Law says: concurrency = throughput x latency.
It turns capacity questions into arithmetic. To serve 2,000 requests per second at 50 ms each, you need 2,000 x 0.05 = 100 requests in flight at once. That number sizes your threads and instances.
Why They Still Trade Off
So why does everyone call them a trade-off?
Because a real system has a capacity limit, and latency gets worse quickly near that limit. Utilization is the share of capacity you are using. Once the servers are busy, a new request waits in a queue before anyone starts working on it. That queue wait is added to every response time.
The curve has three zones:
- Up to about 70 percent utilization, latency is nearly flat.
- Between 70 and 90 percent, latency climbs, and each extra unit of load returns less throughput.
- Past about 90 percent, throughput stops growing and latency rises steeply.
This is why teams run servers at 50 to 70 percent utilization instead of 95. The spare capacity is not waste. It is what keeps response times stable when traffic rises suddenly.
The general form of the trade: you can turn spare capacity into throughput, and latency pays for it. Batching is the clearest example. Batching means collecting many items and processing them in one operation. Writing 100 records in one database call is far cheaper per record, so throughput rises. But the first record now waits for the other 99 to arrive, so its latency gets worse.
Averages Hide the Slow Requests
"Our average latency is 200 ms" tells you almost nothing. An average hides the shape of the data. Most requests are fast, and a few are very slow because of retries, pauses, and locks. Those slow requests barely change the average, and they are exactly what users complain about.
So real systems measure percentiles. Sort all requests from fastest to slowest:
- p50, the median: half of all requests are faster. The typical experience.
- p95: 95 percent are faster. One request in 20 is slower.
- p99: 99 percent are faster. This describes the slowest users, and it is usually the number in a service level objective, a promised performance target.
A p50 of 100 ms with a p99 of four seconds means one request in a hundred is too slow to use.
The slow one percent matters more than it sounds, because one page load is rarely one request. Say a screen makes 100 backend calls, each with a p99 of one second. The chance that all 100 are fast is 0.99 multiplied by itself 100 times, about 0.37. So about 63 percent of page loads include at least one slow call. Once one action becomes many calls, the slow tail becomes the normal experience.
So state every latency requirement as a percentile. "p99 under 200 ms for the timeline endpoint" is a requirement. "Fast" is not. The Key Characteristics of Distributed Systems lesson covers these measurements alongside availability and reliability.
How to Improve Each One
To improve latency:
- Move the data closer. A CDN, a network of servers placed near users, removes physical distance from the round trip.
- Cache. A cache is a small fast store that keeps ready-made answers. A hit skips the slow work entirely.
- Cut round trips. Every sequential network call adds its full latency. Fetch in parallel, or combine related calls.
- Index and tune queries. Most surprise latency is a query doing extra work.
- Do less on the request path. Move anything the user does not need immediately into a background job.
- Keep utilization moderate. Often the cheapest latency fix of all.
To improve throughput:
- Add machines. Instances behind a load balancer. Horizontal vs Vertical Scaling is the next lesson.
- Raise concurrency. More workers, threads, or connections. Little's Law tells you how many.
- Batch. Group work to cut per-item overhead, and accept the added waiting.
- Queue work. Consumers process jobs at their own rate, and the queue absorbs bursts.
- Split the data. Sharding spreads load across machines, so no single database caps the total.
- Cache. Yes, again.
A Cache Improves Latency First
A cache appears in both lists, and it is often filed wrongly.
The first effect of a cache is on latency. The answer is closer and already computed, so the request skips the slow work. That is the same reason a CDN is a latency tool.
The throughput gain follows from the same hit. The backend never did that work, so its capacity is free for other requests. One video processed once and served from a cache to a thousand viewers is a thousand times less backend work. So a cache cuts latency directly, and it usually raises throughput as a consequence. If you had to file it under one number, file it under latency.
Most good techniques help both numbers. The ones that truly trade add waiting on purpose. Batching, buffering, and queueing all raise throughput by making single requests wait longer.
The Two Numbers Side by Side
| Latency | Throughput | |
|---|---|---|
| Measures | Time for one request | Requests completed per second |
| Unit | Milliseconds | RPS or QPS |
| Better is | Lower | Higher |
| Report it as | A percentile, such as p99 | Peak load, not average |
| Improved by | Closer data, caching, fewer round trips | More machines, concurrency, batching |
| Gets worse when | Utilization nears capacity | One serial step limits all the work |
Choosing What to Optimize
- A user is waiting on the request path: optimize latency, and state the target as a percentile.
- Nobody waits on the result, such as a nightly report: optimize throughput. Latency is cheap to spend here.
- The system is overloaded: add capacity or shed load first. Near the limit, both numbers are bad.
- You are given a scale requirement: convert it into both numbers before you design anything.
💡 In the interview: turn the scale requirement into both numbers before you draw a box. "One million daily users, five feed loads each" is about 58 requests per second on average, and peak is several times that. Then size the fleet with Little's Law. Attach a percentile to every latency target. Expect the follow-up "how would you reduce latency" and answer with a cache or a CDN first. Add that the cache also unloads the database, so throughput rises too. If asked why not run servers at 95 percent utilization, answer with the curve: a small traffic rise would push latency past the target.
Key takeaway: latency is the time one request takes, and throughput is the number of requests finished per second. They are independent axes joined by Little's Law: concurrency = throughput x latency. They trade off near capacity, where queueing adds waiting to every request, and when you batch on purpose. Measure latency with percentiles, because the average hides the slow tail that users notice. And a cache improves latency first, because the answer is close and precomputed; the throughput gain follows because the backend skips that work.
Discussion
On This Page