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
Batch Processing vs Stream Processing
batch processing
stream processing
throughput
A payroll system calculates salaries once a month. A fraud detection system must decide whether a card payment looks suspicious before the payment completes, in a fraction of a second.
Both systems process data. But they need the answer at very different times, and that changes how each system is built.
This lesson compares batch processing and stream processing, explains the new problems that streaming brings, and shows how to choose between them.
Two Ways to Process Data
- Batch processing collects data over a period of time, and processes it all together, on a schedule.
- Stream processing handles each record as it arrives, and never stops.
The choice is not about which approach is more modern. It depends on one question: how stale can the answer be? A stale answer is one built from old data. Batch answers are usually hours old. Stream answers are usually seconds old, and that freshness costs more.
Batch Processing
In batch processing, data collects in a storage system, like a data lake or a data warehouse. Then a job runs over the whole collection on a schedule, for example every hour, every night, or every month.
The input is bounded, which means it has a clear start and end. The job sees a complete set of records, and that gives it real advantages:
- It can see all the data at once. It can sort the full dataset, join two very large tables, and read the same records several times.
- Failures are easy to recover from. If a nightly job crashes halfway, the team fixes the bug and runs it again on the same input. If the job is written to be repeatable, the result is the same.
- It is cheap and simple. The work runs in bursts, often on low-cost spare capacity, and nothing runs between jobs.
Common tools: Apache Spark, Hadoop MapReduce, and schedulers like Apache Airflow.
Good fits: payroll, monthly billing, nightly reports, loading a data warehouse, retraining a machine learning model, and backfills, which means processing historical data again.
The cost is freshness. The answer is only as fresh as the last run. If the job runs at 2 AM, a question asked at 3 PM is answered with data that is about 13 hours old.
Batching Writes in Real-Time Systems
Batching is not only for nightly jobs. Write-heavy systems also group small writes together, which is called write batching or buffering. This reduces the overhead on the database, because many rows share one database call.
For example, suppose writing one row per database call takes 2 ms. That gives at most 500 rows per second. If the service writes 500 rows in one call that takes 50 ms, it can write up to 10,000 rows per second. Throughput rises. But each row waits longer until its batch is full. Very large batches make this waiting even longer. The Latency vs Throughput lesson explains this trade in detail.
Stream Processing
In stream processing, records are processed as they arrive, one at a time or in very small groups. The input is unbounded, which means it never ends. So the job runs all the time, and the answer is only seconds behind.
Detecting fraudulent card payments in real time is a classic example. The system must check each payment as it happens. An answer that arrives tomorrow, after a nightly batch job, would be useless.
The hard part of streaming is that the system never holds the complete dataset. It works with an endless sequence of records, and it must decide how much to keep in memory. This creates three ideas that batch processing does not need.
Windows
The stream never ends, so a count needs a boundary. A window is that boundary, like "purchases in the last five minutes". There are three common kinds:
- Fixed windows, also called tumbling windows: each five-minute block is counted separately.
- Sliding windows: the last five minutes, updated every minute.
- Session windows: one user's activity, grouped together until the user is inactive for some time.
Late Events
A customer makes a purchase on a phone at 10:02. The phone loses its signal in a tunnel, and uploads the event at 10:12. But the window from 10:00 to 10:05 has already closed, and its count was already reported.
There are three options, and each one has a cost:
- Drop the late event. This is simple, but the count is slightly wrong.
- Wait longer before closing windows, using a watermark. A watermark is a rule for how long the system waits for late records before it closes a window. Results are more complete, but they arrive later.
- Close the window on time, and send a correction later. Results are fast, but the systems that read them must handle updates.
Delivery Guarantees
Suppose a processing server crashes in the middle of handling a record. Was that record processed or not?
Most systems promise at-least-once delivery, so a record may be processed more than once. The processing logic must then be idempotent, which means processing a record twice has the same effect as processing it once. Some tools, like Apache Flink and Kafka Streams, offer exactly-once processing, but it costs more and must be configured on purpose.
Common tools: Apache Flink, Kafka Streams, and Spark Structured Streaming.
Good fits: fraud detection, live dashboards, alerts, and anything where a late answer is as bad as no answer.
The costs: more components to run, harder debugging, and a system that must stay up all the time. A failed batch job can often run again tomorrow. A failed stream job is an incident right now.
Batch vs. Stream
| Batch | Stream | |
|---|---|---|
| Input | Bounded, a complete set | Unbounded, never ends |
| Runs | On a schedule | All the time |
| Freshness | Hours old | Seconds old |
| Cost per record | Lower, work runs in bursts | Higher, infrastructure always running |
| A failure is | A job to run again | An incident now |
| Processing history again | Easy, run the job on old data | Harder, needs a replay or a second path |
| Complexity | Lower | Higher: windows, late events, and delivery guarantees |
Two rows need a closer look.
Cost per record. Batch is usually cheaper for the same amount of data, because streaming infrastructure keeps running even when little data arrives. If nobody needs the answer sooner, paying for streaming gives no benefit.
Processing history again. Business rules change. Sooner or later, someone asks the team to recalculate the last two years of data under the new rules. Batch does this naturally. A pure streaming system needs a stored log of past events that it can replay, or a separate batch path.
Using Both
Many companies run both on the same data.
- In a Lambda architecture, a streaming path produces fast, approximate numbers for dashboards and alerts. A nightly batch path calculates the same numbers exactly, and replaces them. The cost is that the team maintains the same logic twice.
- In a Kappa architecture, there is only a streaming path. To process history again, the team replays a stored event log through a new version of the job. This works only if the log, often Kafka, keeps events for as long as they might be needed.
Choosing Between Them
Ask the same question again: how stale can this answer be before it stops being useful?
- A day is fine: use batch. It is cheaper and simpler, and simpler systems break less often.
- The answer is useless after a few seconds: use streaming. Fraud checks, alerts, and live pricing cannot wait.
- A few minutes is fine: consider micro-batching, which means running small batch jobs every few minutes. It is often fresh enough, with much less infrastructure.
- History will need to be recalculated: keep a batch path, or an event log that can be replayed.
Using This in an Interview
Do not choose streaming just because it sounds impressive. Interviewers notice when a design adds Kafka and Flink for users who would not notice a nightly update. First state how fresh the data must be, and then choose.
If you choose streaming, expect follow-up questions about windows and late events, because that is where the real design work is. A concrete answer helps. For example: "Five-minute fixed windows, a two-minute watermark, and events that arrive later go to a correction stream."
Key Takeaways
- Batch processing handles a bounded set of data on a schedule. It is cheap, simple, and easy to run again, but its answers are hours old.
- Stream processing handles an unbounded flow of records all the time. Its answers are seconds old, which makes it right for cases like real-time fraud detection.
- Streaming brings new problems: windows, late events, and delivery guarantees.
- Batching writes raises throughput and reduces database overhead, but each item waits longer while its batch fills.
- Decide by asking how stale the answer can be, and state the number.
- Large systems often run both, with a fast streaming path and an exact batch path, or a replayable event log.
Batch and stream processing trade freshness against cost and complexity. The next lesson, SQL vs. NoSQL, moves to a different decision: how to store the data in the first place.
Practice Questions
Try each question first, then open the answer.
1. A report job runs every night at 2 AM, using all data collected until then. A manager opens the report at 3 PM. How old is the newest data in the report?
<details> <summary>Show answer</summary>About 13 hours old. The job included data only up to 2 AM. From 2 AM to 3 PM is 13 hours, so nothing from those 13 hours is in the report. If the manager needs fresher numbers, the team can run the job more often, use micro-batching, or use streaming.
</details>2. A bank must decide whether a card payment looks fraudulent before the payment is approved. Should it use batch processing or stream processing?
<details> <summary>Show answer</summary>Stream processing. The decision is needed within a fraction of a second, while the payment is happening. A batch job that runs later would find the fraud only after the money is gone. A stream processor checks each payment as it arrives.
</details>3. Writing one row per database call takes 2 ms. The team changes the service to write 500 rows in one call, which takes 50 ms. Rows arrive at 1,000 per second. What happens to throughput and to the waiting time for each row?
<details> <summary>Show answer</summary>Throughput rises from 500 to up to 10,000 rows per second, but rows wait longer. One row per call allows 1,000 ms / 2 ms = 500 rows per second, which cannot keep up with 1,000 arriving rows. Batches of 500 in 50 ms allow up to 10,000 rows per second. But a batch of 500 takes about 0.5 seconds to fill. So the first row in each batch waits about 0.5 seconds, plus the 50 ms write.
</details>4. A stream job uses five-minute fixed windows. A purchase made at 10:02 arrives at 10:12, after the 10:00 to 10:05 window was reported. What are the options, and what does each one cost?
<details> <summary>Show answer</summary>Drop it, wait longer with a watermark, or send a correction. Dropping the event is simple, but the count for that window is slightly wrong. A watermark that waits 10 minutes would include it, but every window's result would arrive 10 minutes later. Reporting on time and sending a correction keeps results fast, but readers must handle updated counts.
</details>5. A company uses only stream processing, and Kafka keeps events for 7 days. A new business rule requires recalculating the last two years of data. What is the problem, and what could the team do?
<details> <summary>Show answer</summary>The event log does not go back far enough to replay two years. A Kappa-style design can recalculate only the history that its log still holds, here 7 days. The team needs another copy of the history, like raw events stored in a data lake, and a batch job to process it. In the future, they could keep events longer, or keep a batch path for this kind of request.
</details>Discussion
On This Page