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
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
DNS Load Balancing and High Availability
dns
load balancing
availability
distributed systems
+2
A video site has servers in Europe, North America, and Asia. A user in Tokyo types the site's name. A user in Madrid types the same name at the same moment.
Both users should reach a server near them. And if the servers in Asia fail, the user in Tokyo should still reach the site.
The first decision happens before any request reaches a server. It happens when DNS chooses which IP address to return. This lesson explains how DNS uses that choice to spread load and to keep a service available.
Why DNS Can Balance Load
A DNS server does not have to give every user the same answer. For one name, it can return different IP addresses to different users, or change the answer over time.
That choice happens during name resolution, before any traffic reaches your servers. So DNS can do two useful jobs.
- Spread load. Send different users to different servers.
- Improve availability. Stop sending users to a server or a location that has failed.
There are four common techniques: round-robin DNS, geographically distributed DNS servers, anycast routing, and CDNs that use DNS.
Round-Robin DNS
Round-robin DNS is the simplest technique. Several IP addresses are associated with one domain name. When resolvers ask for that name, the DNS server rotates through the addresses, returning them in a different order each time.
For example, example.com has three A records: 203.0.113.10, 203.0.113.11, and 203.0.113.12. The first query gets .10 first, the next query gets .11 first, and the next gets .12 first. Most clients use the first address in the list, so requests are spread across the three servers.
Round-robin DNS is easy to set up, and it improves both performance and availability.
The Limits of Round-Robin DNS
Round-robin DNS does not know how busy each server is, or where the user is. It only rotates through the list. This causes several problems.
- Uneven load. A large resolver can serve thousands of users. It may cache one answer and give the same first address to all of them until the TTL expires. So one server can receive far more traffic than the others.
- Distance. A user in Madrid may receive the address of a server in Asia, while a closer server has little traffic.
- Failed servers still get traffic. DNS does not check whether a server is healthy. If one server crashes, its address is still returned in answers. Even after someone removes it, cached copies keep sending users there until their TTL expires. Some clients try the next address after a failure, but many users still see errors.
Smarter DNS Answers
Many DNS services go beyond simple rotation. They choose each answer with more information.
- Health-checked DNS. The DNS service checks each server regularly, for example with an HTTP request every 30 seconds. When a server fails its checks, its address is removed from the answers.
- Weighted DNS. Each address gets a share of the answers. For example, 90 percent of answers point to the current version of a service and 10 percent to a new version.
- Location-based DNS. The DNS server returns the address of the region closest to the user. It usually judges this from the location of the user's resolver. Some resolvers also pass part of the user's IP address, so the answer matches the user's location more closely.
All of these are still affected by caching. A change in the answer reaches users only after the cached answers expire. So services that use DNS for failover usually set short TTLs, like 30 to 60 seconds.
Geographically Distributed DNS Servers
DNS servers themselves can also be spread across many locations, instead of sitting in one data center.
This gives two benefits.
- Faster resolution. Users get answers from a DNS server near them, so each lookup takes less time.
- Redundancy. One location can become unreachable because of a server failure or a network outage. Users can then still be served by DNS servers in other locations.
Every large DNS provider works this way. So do the root servers, which the next section explains.
Anycast Routing
Anycast lets multiple servers in different places share the same IP address.
Here is how it works. Each location tells the internet's routers that it can reach that IP address. Routers share this information with a protocol called BGP (Border Gateway Protocol), which is how networks tell each other which addresses they can reach. When a query is sent to the shared address, the network delivers it to the nearest location. Routers judge this by factors like network distance and availability.
The user does not choose, and the DNS operator does not choose. The network's routing chooses.
Anycast gives three benefits at once.
- Load balancing. Queries are spread across many servers, so no single server becomes a bottleneck.
- Lower latency. Each user reaches a nearby server, which reduces resolution time.
- High availability. If one location fails, it stops announcing the address. The network then automatically sends queries to the next closest location that shares the same IP address. No one has to change any configuration.
Anycast suits DNS very well because a DNS query is usually one short question and one short answer. The 13 root server clusters use anycast, which is how each one can be made of many servers around the world. Public resolvers like 1.1.1.1 and 8.8.8.8 also use it.
The difference from round-robin DNS is important. Round-robin gives out different addresses and does not consider where users are. Anycast gives out one address, and the network delivers each request to a nearby location.
CDNs and DNS
A Content Delivery Network (CDN) is a network of distributed servers that cache and deliver web content to users based on their location. It improves performance, reliability, and security by spreading load across many servers and serving each user from a nearby server.
DNS is how a CDN sends each user to a nearby server. Here are the steps.
- The website points its name to the CDN with a CNAME record. For example,
www.example.combecomes an alias forexample.cdnprovider.net. - A user's resolver looks up
www.example.comand follows the CNAME to the CDN's name. - The CDN's own DNS server chooses the best edge server for this user, based on location, server load, and other factors.
- It returns that edge server's IP address, and the user's browser connects there.
So the routing decision happens during name resolution, before any content is sent. CDNs usually use short TTLs, so they can send users to a different edge server quickly when one is busy or has failed. The What is CDN? lesson covers CDNs in more detail.
Where DNS Load Balancing Stops
DNS is useful for spreading load, but it has limits.
- Caching delays every change. Resolvers, operating systems, and browsers keep answers until the TTL expires, and sometimes longer.
- No control over single requests. DNS picks an address for a lookup, not for each request. One cached answer can be used for thousands of requests.
- Limited knowledge of servers. DNS does not see how busy each server is right now.
So large systems usually combine two layers. DNS, often with anycast or location-based answers, picks the region. Inside each region, a load balancer spreads requests across healthy servers, and it reacts to failures in seconds. The load balancing chapter explains load balancers.
| Technique | How it chooses | Main weakness |
|---|---|---|
| Round-robin DNS | Rotates through several addresses | Ignores server load and user location |
| Health-checked, weighted, or location-based DNS | Uses health, weights, or location | Changes wait for caches to expire |
| Geographically distributed DNS servers | Users reach a DNS server nearby | You must run and manage many locations |
| Anycast | One address, the network picks the nearest site | Depends on internet routing |
| CDN with DNS | The CDN's DNS returns the best edge server | Helps most for content that can be cached |
Key Takeaways
- DNS can choose which IP address to return, so it can spread load and avoid failed servers before traffic reaches them.
- Round-robin DNS rotates through several addresses for one name. It ignores each server's real load and the user's location, so traffic can be uneven.
- Health-checked, weighted, and location-based DNS choose answers with more information, but every change waits for cached answers to expire.
- Geographically distributed DNS servers give nearby users faster answers and keep working if one location fails.
- Anycast lets many servers share one IP address. The network routes each query to the nearest server, and it fails over to the next closest one automatically.
- A CDN uses its own DNS server to return the address of the best edge server for each user.
- Large systems use DNS to pick a region, and load balancers to spread requests inside it.
DNS gives every user an address, and the choice of that address is the first place a system can spread load and avoid failures. That completes the DNS 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. example.com uses round-robin DNS with three A records, and one of the three servers crashes. What happens to users, and why is round-robin DNS alone risky here?
Some users are still sent to the crashed server. Round-robin DNS does not check server health, so it keeps returning the failed address. Even after someone removes the address, cached copies keep sending users there until their TTL expires. Some clients retry another address, but many users see errors. Health-checked DNS or a load balancer avoids this.
</details>2. A site uses round-robin DNS, and every query gets the addresses in a different order. Why can one server still receive much more traffic than the others?
<details> <summary>Show answer</summary>Because answers are cached and shared. A large resolver can serve thousands of users. It may cache one answer and give the same first address to all of them until the TTL expires. Round-robin DNS also ignores how busy each server is, and some requests need much more work than others.
</details>3. A DNS service uses anycast, with the same IP address announced from sites in Tokyo, Frankfurt, and Virginia. The Tokyo site goes offline. What happens to users in Tokyo?
<details> <summary>Show answer</summary>Their queries automatically reach the next nearest site. When the Tokyo site goes offline, it stops announcing the shared address. The network then routes queries for that address to another site, like Virginia or Frankfurt. Users do not change any settings, and the DNS operator does not change any records. Answers may be slower because the site is farther away.
</details>4. A website uses a CDN. How does DNS send a user in Madrid to an edge server in Madrid, instead of a server on another continent?
<details> <summary>Show answer</summary>The CDN's own DNS server chooses the edge server. The website's name is a CNAME alias for the CDN's host name. When the user's resolver looks it up, the CDN's DNS server sees where the query comes from. It returns the IP address of a nearby edge server in Madrid, and the browser connects there.
</details>5. A team wants to send 10 percent of its users to a new version of a service. Which DNS technique fits, and what is its main drawback?
<details> <summary>Show answer</summary>Weighted DNS. It returns the new version's address in about 10 percent of answers. The drawback is caching. One resolver's cached answer may serve many users, so the real split is only approximate. Changing the weights also takes effect only after the TTL expires. A load balancer can split traffic per request, much more precisely.
</details>Discussion
On This Page