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
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
URL vs. URI vs. URN
api design
caching
security
You send a friend this link to a product:
https://shop.example.com/products/42?color=red#reviews
Your friend opens it and sees the reviews section of the red version of that product. Every part of the link had a purpose. One part told the browser how to connect, one told it which server to ask, and one told it which product to show.
This lesson explains each part of a link like this one. It also explains three terms that people often mix up: URI, URL, and URN.
Three Terms, One Family
The three terms are related. One is the general term, and the other two are special kinds of it.
- A URI (Uniform Resource Identifier) is any string that identifies a resource. It can identify the resource by its location, by its name, or by both.
- A URL (Uniform Resource Locator) is a URI that also tells you how and where to reach the resource.
- A URN (Uniform Resource Name) is a URI that gives the resource a permanent name, without saying where it is.
A resource here means anything that can be identified: a web page, an image, a file, a book, or a person's account.
All URLs and URNs are URIs. But not every URI is a URL or a URN.
URI
A URI identifies a resource. It is the most general of the three terms.
Every URI follows the same basic pattern. It starts with a scheme, followed by a colon, and then the rest of the identifier.
scheme:rest-of-the-identifier
Here are a few URIs with different schemes.
https://www.example.com/aboutidentifies a web page.mailto:support@example.comidentifies an email address.urn:isbn:0451450523identifies a book.
Each one identifies something. Only some of them tell you where that thing is.
URL
A URL is a URI that identifies a resource and describes how to get it, usually by its network location. A URL answers two questions: how to reach the resource, and where it is.
The Parts of a URL
Here is a full URL, with every optional part included.
https://shop.example.com:443/products/42?color=red&size=m#reviews
It has six parts.
- Scheme (
https). The protocol to use, like HTTP, HTTPS, or FTP. - Host (
shop.example.com). The domain name of the server. The browser uses DNS to find the server's IP address from this name. - Port (
443). The port on the server. It is usually left out, because each scheme has a default: 80 for HTTP and 443 for HTTPS. - Path (
/products/42). Which resource on the server you want. - Query (
?color=red&size=m). Extra options for the request, written askey=valuepairs and separated by&. - Fragment (
#reviews). A position inside the resource, like one section of a page.
The fragment is never sent to the server. The browser keeps it and uses it after the page loads, for example to scroll to the reviews section. So the server receives the same request with or without #reviews.
In short, a URL is made of a protocol, a domain name, and a path. It can also include query parameters and a fragment.
Special Characters
A URL can contain only certain characters. Spaces and many symbols must be written in a special form called percent-encoding. Each such character becomes a % sign followed by two hexadecimal digits.
For example, a space becomes %20. So a search for "red shoes" can appear as ?q=red%20shoes.
Absolute and Relative URLs
An absolute URL includes the scheme and host, like https://shop.example.com/images/logo.png.
A relative URL leaves them out, like /images/logo.png. The browser fills in the missing parts from the page it is on. Web pages use relative URLs for their own files, so the same page works on any domain.
URN
A URN is a URI that names a resource with a unique and permanent identifier. It does not say how to locate the resource. A URN answers only one question: what is this?
URNs follow this pattern.
urn:namespace:identifier
The namespace says which naming system the identifier comes from. Here are two examples.
urn:isbn:0451450523identifies one book by its ISBN, the international book number.urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66identifies an object by a UUID, a 128-bit ID that is unique for all practical purposes.
The book's URN stays the same no matter where copies of the book are stored, or whether a copy exists online at all.
A URN cannot be opened directly. To get the resource, a system needs a resolver, which is a service that looks up a name and returns a current location. For example, a library system can look up a book's URN and return the file's current URL. If the file moves, only the resolver's record changes. The URN stays the same.
URL vs. URN
| URL | URN | |
|---|---|---|
| What it gives | How and where to reach a resource | A permanent name for a resource |
| Example | https://example.com/books/42.pdf | urn:isbn:0451450523 |
| Can a browser open it? | Yes | No, it needs a resolver |
| If the resource moves | The URL can break | The URN still works |
| Is it a URI? | Yes | Yes |
This table explains the sentence that often confuses people. Every URL is a URI, because locating a resource is one way of identifying it. Not every URI is a URL, because a URI can be a URN, which only names a resource and gives no location.
A note on everyday language. Almost every identifier you use on the web is a URL. So in practice, many people and web standards simply say "URL" for any web address. Technical specifications often use "URI" as the general term.
Why This Matters in System Design
The terms matter less than the ideas behind them. Three of those ideas come up often.
Stable identifiers in APIs. Suppose an API returns each order's full URL, like https://api.example.com/v1/orders/9001. Every client now depends on that host and path. If the API moves to /v2, stored links break. Returning a stable ID, like 9001, lets clients build the URL when they need it. This is the same idea as a URN: a name that does not change when the location does.
Cache keys. Caches and CDNs usually store each response under its full URL. So ?color=red&size=m and ?size=m&color=red can be stored as two different entries, even though they mean the same thing. Keeping query parameters in a fixed order makes caching work better.
Never put secrets in a URL. URLs are saved in browser history, server logs, proxy logs, and analytics tools, and they are easy to share by mistake. Passwords and API keys should go in request headers or the request body instead. If a link must contain a token, as in a password reset link, the token should work only once and expire quickly.
Key Takeaways
- A URI (Uniform Resource Identifier) is the general term for any identifier of a resource, by location, name, or both.
- A URL (Uniform Resource Locator) is a URI that says how and where to reach a resource.
- A URL has a scheme, host, and path, and can also have a port, query parameters, and a fragment. The fragment is never sent to the server.
- A URN (Uniform Resource Name) is a URI that names a resource permanently, like
urn:isbn:0451450523, without giving its location. - All URLs and URNs are URIs, but not every URI is a URL or a URN.
- In system design, prefer stable IDs over stored URLs. Also keep query parameters in a fixed order for caching, and keep secrets out of URLs.
A URL tells a browser where to go. A URN tells a system what something is, wherever it is. The next lesson is What Happens When You Type a URL into the Browser. It follows a URL from the address bar to a finished page, using every idea from this chapter.
Practice Questions
Try each question first, then open the answer.
1. Name each part of this URL: https://api.example.com:8080/v1/orders?status=open&page=2#top
Scheme https, host api.example.com, port 8080, path /v1/orders, query status=open&page=2, and fragment top. The query has two parameters, status and page. The port is written here because 8080 is not the default HTTPS port. The fragment stays in the browser and is not sent to the server.
2. Is https://example.com/books/42 a URL, a URN, or a URI? What about urn:isbn:0451450523?
The first is a URL, and the second is a URN. Both are URIs. The first one says how to reach the resource (HTTPS) and where it is (a host and a path). The second one only names a book by its ISBN and says nothing about location. Every URL and every URN is also a URI.
</details>3. A digital library needs an identifier for each book that stays valid, even when files move between storage systems. Should it use URLs or URNs? What else does it need so readers can open a book?
<details> <summary>Show answer</summary>URNs, plus a resolver. A URN names the book permanently and does not depend on where the file is stored. A URL would break as soon as the file moved. To open a book, the library needs a resolver service that looks up the URN and returns the file's current URL.
</details>4. A marketing team wants to count how many visitors open https://example.com/pricing#faq by reading the server logs. Why will this fail?
The fragment is never sent to the server. The browser requests only https://example.com/pricing and keeps #faq for itself. The server logs cannot tell these visits apart from normal visits to the pricing page. To count them, JavaScript on the page must read the fragment and report it, or the link must use a query parameter instead.
5. A developer sends an API key in a query parameter, like ?api_key=abc123. Why is this risky, and where should the key go instead?
URLs are recorded in many places. They are saved in server logs, proxy logs, browser history, and analytics tools, so the key can leak without anyone noticing. The key should go in a request header, like Authorization, over HTTPS. Like the URL, headers are encrypted over HTTPS, but they are not usually written to access logs.
Discussion
On This Page