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
Scalability
scalability
horizontal scaling
vertical scaling
availability
+3
Your team runs a website that sells tickets for soccer matches. On a normal day, about 2,000 people visit it. Then tickets for a cup final go on sale. In the first ten minutes, 200,000 people open the site at the same time.
The pages slow down. Then the server stops answering, and most people never get a ticket.
The code did not change. Only the amount of work changed. This lesson answers two questions. How does a system handle more work as it grows? And how should we design it so that adding machines actually helps?
What Scalability Means
Scalability is the ability of a system to handle a growing workload by adding resources. A scalable system keeps working well as users, requests, and data grow.
A workload can grow in several ways.
- More requests. Traffic is often measured in requests per second (RPS), the number of requests the system receives each second.
- More data. The database grows from 10 GB to 10 TB.
- More users in more places. Users in Chennai and users in London both expect a fast response.
Here is a simple example. One app server can handle 500 requests per second. At peak time, the site gets 2,000 requests per second. If the system scales well, four servers can handle that peak.
Scalability is not the same as speed. Performance is how fast the system answers one request. Scalability is whether it stays fast when the number of requests grows. A system can answer one user in 50 ms and still fail when 10,000 users arrive together.
There are two ways to add resources. You can make one machine bigger, or you can add more machines.
Vertical Scaling
Vertical scaling, also called scaling up, means increasing the capacity of one machine by upgrading its hardware. You give it more CPU, more memory, or more storage.
For example, a database server has 8 CPU cores and 32 GB of memory. The team moves it to a machine with 64 cores and 512 GB. The same single machine now handles more work. This is a common way to grow a relational database like MySQL.
Vertical scaling has real benefits.
- It is simple. The application code usually does not change.
- There is still only one machine to run, watch, and back up.
- All data stays in one place, so every read sees the latest write.
It also has hard limits.
- There is an upper limit. You cannot buy a machine bigger than the biggest machine available.
- The biggest machines are expensive. Their price usually grows faster than the capacity they add.
- Upgrading usually needs downtime. The machine often has to restart on the new hardware.
- It is still one machine. If it fails, everything on it stops. It is a single point of failure.
Horizontal Scaling
Horizontal scaling, also called scaling out, means adding more machines, called nodes, so the workload is spread evenly across them. A load balancer sits in front of the nodes. It is a server that sends each incoming request to one of them.
No single machine has to handle all the growth. When more requests arrive, more machines share them.
Horizontal scaling has strong benefits.
- There is no fixed limit. You can keep adding machines.
- Capacity can grow while the system runs. New machines join the pool without downtime.
- It is cost-effective when traffic goes up and down. You add machines for a sale day and remove them afterwards.
- One failure is not an outage. If one machine fails, the others keep serving requests.
Databases like Cassandra and MongoDB are built to scale this way. You add nodes as the data and traffic grow.
Horizontal scaling also has costs. There are more machines to deploy and watch. Machines talk over the network, which adds delay and new ways to fail. Also, the application must be designed so that any machine can handle any request.
| Vertical (scaling up) | Horizontal (scaling out) | |
|---|---|---|
| What changes | Size of one machine | Number of machines |
| Upper limit | The biggest machine available | No fixed limit |
| Adding capacity | Usually needs downtime | Add nodes while running |
| One machine fails | Everything on it stops | The others keep working |
| Code changes | Usually none | The app must be designed for it |
| Examples | MySQL | Cassandra, MongoDB |
Most real systems use both. Teams often scale up first because it is simple. They scale out when they reach the limit of one machine, or when the system must keep working after a machine fails.
Stateless Servers
Horizontal scaling works only when any server can handle any request. The main thing that breaks this is state.
State is data a server remembers between requests, like a user's login session or shopping cart. A server that keeps this data in its own memory is called stateful.
Here is the problem. A user adds a phone to the cart, and the load balancer sends that request to Server A. Server A stores the cart in its memory. The next request goes to Server B, and Server B has no cart for this user. The user sees an empty cart.
The fix is to move state out of the servers. Every server stores sessions and carts in one shared store, like Redis or a database. A server that keeps no user data between requests is called stateless.
Now every server reads the same cart. The load balancer can send any request to any server. Adding a server is as simple as starting it and adding it to the load balancer.
Some load balancers can send a user back to the same server every time. This is called a sticky session. It hides the problem, but it does not fix it. If that server fails, its users lose their sessions. Many busy users can also end up on one server and overload it. The stateful vs. stateless architecture lesson covers this in more detail.
Scaling the Database
Stateless app servers are easy to scale. The database is usually harder to scale because it now holds all the state. It often becomes the bottleneck, which is the one part that limits the capacity of the whole system.
Teams usually scale a database in steps, starting with the simplest one.
1. Add a cache. A cache is fast storage in memory, like Redis, that keeps copies of data that is read often. Suppose 80 percent of reads ask for the same popular items. The cache answers those reads, and the database handles only the rest. The caching chapter covers this in detail.
2. Add read replicas. A read replica is a copy of the database that serves read requests. The primary database accepts all writes and copies them to the replicas. This helps most when reads are much more common than writes, which is true for many apps. A replica can be a little behind the primary, so a read may briefly return old data.
3. Split the data into shards. When writes or data size outgrow one machine, the data is split across several databases. Each part is called a shard, and the method is called sharding or partitioning. For example, users with IDs from 1 to 1,000,000 go to shard 1, and the next million go to shard 2. Each shard holds part of the data and takes part of the writes.
Sharding adds the most work. A query that needs data from many shards is slower and harder to write. Moving data when you add a shard is also hard. So teams shard only when the simpler steps are not enough. The data partitioning chapter explains the methods.
Other Ways to Scale
Content delivery network. A CDN is a group of servers in many cities that stores copies of static files, like images, videos, and scripts. Users download these files from a nearby CDN server instead of from your servers. This removes a large share of traffic from your system. The CDN chapter explains how it works.
Message queues. Some work does not need to finish before the user gets a response. Examples are sending an email, creating an invoice, or resizing a photo. A message queue stores these jobs until a worker is ready. Workers are separate machines that take jobs from the queue and process them. When the queue grows, you add more workers. The user gets a fast response, and the slow work happens in the background.
Autoscaling. Autoscaling means adding or removing servers automatically, based on a measured number like CPU use. For example, one rule adds a server when average CPU stays above 70 percent for 5 minutes. Another rule removes a server when average CPU stays below 30 percent. A food delivery app can then run 20 servers at lunch and 5 servers at night. Autoscaling needs stateless servers because servers start and stop all the time.
Finding the Bottleneck
Adding machines helps only if the machines were the problem. Suppose a team doubles its app servers from 10 to 20. If every request still waits on one busy database, capacity hardly grows.
Linear scaling is the ideal case, where doubling the machines doubles the capacity. Real systems get less than that. Shared parts, like one database, limit the gain. Machines also spend time talking to each other.
So teams measure before they scale. They use load testing, which means sending a large amount of test traffic to a copy of the system. They raise the traffic step by step and watch each part. The first part to reach its limit is the bottleneck. For example, database CPU reaches 100 percent, or queries start taking seconds instead of milliseconds.
The team fixes that part and tests again. After each fix, the next bottleneck appears in a different part.
Key Takeaways
- Scalability is the ability to handle a growing workload by adding resources, while the system stays fast.
- Vertical scaling (scaling up) makes one machine bigger. It is simple, but it has an upper limit, usually needs downtime, and is a single point of failure.
- Horizontal scaling (scaling out) adds machines and spreads the work across them. It has no fixed limit and keeps working when one machine fails, but the app must be designed for it.
- Horizontal scaling needs stateless servers. Keep sessions and carts in a shared store.
- The database is often the bottleneck. Scale it in steps: a cache, then read replicas, then shards.
- CDNs and message queues move work away from the core system. Autoscaling matches the number of servers to the traffic.
- Load test before you scale. Adding machines does not help when the bottleneck is somewhere else.
A scalable design does not need every technique in its first version. It needs parts that can grow without a rewrite, like stateless servers and state kept in shared stores. It also needs a clear idea of which part will become the bottleneck next. The next lesson, Availability, covers how to keep such a system running when some of its machines fail.
Practice Questions
Try each question first, then open the answer.
1. One app server handles 400 requests per second. Peak traffic is 3,000 requests per second, and you want to handle 25 percent more than the peak. How many servers do you need?
<details> <summary>Show answer</summary>10 servers. The target is 3,000 x 1.25 = 3,750 requests per second. Each server handles 400, so you need 3,750 / 400 = 9.375 servers. You cannot run part of a server, so round up to 10.
</details>2. A shopping app keeps each user's cart in the memory of its app server. After the team adds two more servers behind a load balancer, users report empty carts. Why, and what is the fix?
<details> <summary>Show answer</summary>The servers are stateful. The cart lives in the memory of one server. The load balancer sends the next request to a different server, which has no cart for that user. The fix is to store carts in a shared store, like Redis or a database, so every server is stateless. Sticky sessions only hide the problem, because users still lose their carts when their server fails.
</details>3. A database receives 9,000 reads and 1,000 writes per second, and it is near its limit. Should the team add read replicas or shard the data first?
<details> <summary>Show answer</summary>Read replicas first. About 90 percent of the requests are reads, and replicas take that load off the primary. A cache in front of the database helps in the same way. Sharding is the right step when writes or data size outgrow one machine. It adds much more work, so it should come later.
</details>4. Traffic on a food delivery app is 5 times higher at lunch and dinner than late at night. Why is horizontal scaling with autoscaling a good fit?
<details> <summary>Show answer</summary>The number of servers can follow the traffic. Autoscaling adds servers as traffic rises at lunch and dinner, and removes them at night. The team pays for extra servers only while it needs them. With vertical scaling, the one machine must be sized for the peak all day, and changing its size usually needs downtime.
</details>5. A team doubles its app servers from 10 to 20, but the maximum load only rises from 5,000 to 5,600 requests per second. What is the most likely cause, and what should the team do?
<details> <summary>Show answer</summary>The bottleneck is not the app servers. A shared part, most often the database, is already at its limit, so the new servers spend their time waiting on it. The team should load test and measure each part, like database CPU and query time. Then it should fix the real bottleneck, for example with a cache, read replicas, or shards.
</details>Discussion
On This Page