A complete, production-grade learning roadmap from web application fundamentals to high-scale distributed architectures, databases, and consensus protocols.
System Design is the process of deciding how the components of a software system should work together to satisfy a set of requirements.
When we build a small application, we can often put everything on one machine:
User
|
v
Application
|
v
DatabaseThat may work for a small number of users.
But imagine the application suddenly has:
A single server is no longer enough.
The architecture evolves:
+----------------+
| Clients |
+-------+--------+
|
v
+---------------+
| CDN |
+-------+-------+
|
v
+---------------+
| Load Balancer |
+-------+-------+
|
+-------------+-------------+
| | |
v v v
+-------+ +-------+ +-------+
| App 1 | | App 2 | | App 3 |
+---+---+ +---+---+ +---+---+
| | |
+-------------+-------------+
|
+-----------+-----------+
| |
v v
+-----------+ +-----------+
| Cache | | Database |
+-----------+ +-----------+System Design is about understanding why these components are needed, how they interact, what can fail, and what trade-offs are involved.
The main reason is that software systems grow.
A simple application might begin as:
Browser → Server → DatabaseAs usage increases, problems appear.
One server cannot process every request.
Solution:
Load Balancer
/ | \
/ | \
Server Server ServerMillions of requests hit the database.
Possible solutions:
Suppose 100,000 users request the same popular product.
Without caching:
100,000 requests
|
v
DatabaseWith caching:
100,000 requests
|
v
Cache
|
+---- Cache Hit → Return result
|
+---- Cache Miss → DatabaseIf one server fails:
Users → Server X → FAILUREA highly available design might use:
Load Balancer
/ \
v v
Server A Server B
| |
+-----+------+
|
DatabaseIf Server A fails, Server B can continue serving traffic.
There is rarely one universally perfect architecture.
For example:
You may want every user to immediately see the latest data.
Advantage:
Potential cost:
Different replicas may temporarily contain different values.
Advantage:
Trade-off:
System Design therefore involves questions such as:
What are we optimizing for?
Examples:
A strong system designer understands the trade-off instead of simply memorizing technologies.
This distinction is fundamental.
Functional requirements describe what the system should do.
For a URL shortener:
For a messaging application:
Non-functional requirements describe how well the system should perform.
Examples:
A useful mental model:
Functional Requirements
|
| What?
v
What does the system do?
Non-Functional Requirements
|
| How well?
v
How should the system behave?Both are necessary.
Scalability is the ability of a system to handle increasing workload by adding resources or changing architecture.
Suppose our server handles:
1,000 requests/secondTraffic increases to:
10,000 requests/secondWe need to scale.
Make one machine more powerful.
Before:
+-----------+
| 4 CPU |
| 16 GB RAM |
+-----------+
After:
+-----------+
| 32 CPU |
| 128 GB RAM|
+-----------+Advantages:
Limitations:
Add more machines.
Load Balancer
/ | \
v v v
Server Server Server
1 2 3Advantages:
Challenges:
Modern large-scale systems frequently rely heavily on horizontal scaling.
Availability describes how often a system is operational and accessible.
Consider:
System available
|
v
Users can successfully use itAvailability is commonly discussed using percentages.
Examples:
| Availability | Approximate yearly downtime |
|---|---|
| 99% | 3.65 days |
| 99.9% | 8.76 hours |
| 99.99% | 52.6 minutes |
| 99.999% | 5.26 minutes |
The more availability we require, the more engineering effort is generally required.
Techniques include:
Availability and reliability are related but not identical.
Availability asks:
Is the system currently available?
Reliability asks:
Does the system consistently perform correctly over time?
For example, a payment system that is available but occasionally charges users twice is not behaving reliably.
Reliability involves:
Latency is the time required to complete an operation.
Example:
Client
|
| Request
v
Server
|
| 120 ms
v
ClientLatency = approximately 120 ms.
In system design, we often care about:
Why are percentiles important?
Suppose:
99 users → 50 ms
1 user → 5 secondsThe average may hide the experience of that one user.
Tail latency tells us what slower users experience.
Throughput measures how much work a system can process in a period of time.
For APIs, we often use:
Requests per second (RPS)or:
Queries per second (QPS)Example:
Server processes:
10,000 requests/secondIts throughput is approximately:
10,000 RPSOther systems may use:
Capacity is the amount of workload a system can handle while satisfying its requirements.
Suppose:
One server = 2,000 RPSExpected traffic:
10,000 RPSA simplified calculation:
10,000 / 2,000 = 5 serversBut production architecture should account for:
Therefore we might intentionally run more than the mathematical minimum.
Capacity planning becomes a major topic later in the course.
Durability means that successfully stored data should not be lost unexpectedly.
For example, after a payment is recorded, we expect that record to survive:
Durability is commonly improved through:
Consistency describes how users observe data across different copies or operations.
Imagine:
Database Primary
|
+------ Replica A
|
+------ Replica BIf a user updates:
Balance = ₹1,000but a replica temporarily still reports:
Balance = ₹500we have a consistency issue from the user's perspective.
Later we will study:
A fault-tolerant system continues operating despite failures.
Failures can include:
Instead of assuming:
Nothing will fail.
System design assumes:
Something will eventually fail. How does the system respond?
This is one of the most important mindset changes in system design.
A server does not need to remember previous requests locally.
Request 1 → Server A
Request 2 → Server B
Request 3 → Server CAny server can handle any request.
This makes horizontal scaling easier.
A server keeps important session/state information locally.
User → Server A
|
+--- User stateIf the next request reaches Server B, the state may be unavailable.
Stateful systems are not inherently bad, but distributed state requires careful design.
A beginner application might look like:
Internet
|
v
+-------------+
| Web Server |
| Application |
+------+------+
|
v
+-------------+
| Database |
+-------------+This is easy to build.
But consider:
The architecture eventually needs additional components.
A distributed system spreads computation or data across multiple machines.
Example:
Users
|
v
CDN
|
v
Load Balancer
|
+-------------+-------------+
| | |
v v v
App A App B App C
| | |
+-------------+-------------+
|
+----------+----------+
| |
v v
Cache Database
|
+---------+---------+
| |
v v
Replica A Replica BNow we gain:
But complexity increases.
That is a recurring System Design principle:
Distribution solves some problems while creating new ones.
Throughout this course, repeatedly encounter these components:
| Component | Main purpose |
|---|---|
| Client | Sends/receives requests |
| DNS | Resolves domain names |
| CDN | Serves content closer to users |
| Load Balancer | Distributes traffic |
| API Gateway | Entry point for APIs/services |
| Application Server | Executes business logic |
| Cache | Speeds up repeated reads |
| SQL Database | Structured persistent data |
| NoSQL Database | Flexible/distributed data models |
| Object Storage | Large files/media |
| Message Queue | Asynchronous processing |
| Stream Platform | Event streaming |
| Search Engine | Fast text/search queries |
| Monitoring | Observability |
| Service Mesh | Service-to-service infrastructure |
We will study each one deeply.
When you see a system-design problem, think through these layers:
USERS
|
v
NETWORK / DNS
|
v
CDN / EDGE
|
v
LOAD BALANCER
|
v
API / APPLICATION
|
+-------+-------+
| | |
v v v
CACHE QUEUE SEARCH
| | |
+-------+-------+
|
v
DATABASE
|
v
STORAGEThen ask:
How many users?
How many requests?
What is peak traffic?
How much data?
How fast does it grow?
What latency is acceptable?
What happens if a server fails?
How fresh must the data be?
What happens when traffic becomes 10× larger?
What happens when components fail?
Who can access what?
What infrastructure is reasonable?
For almost every design problem, develop the habit of asking:
Define the system.
Understand users and clients.
Functional requirements.
Non-functional requirements.
Estimate scale.
Choose storage.
Caching, indexing, CDN, optimization.
Replication, sharding, horizontal scaling, asynchronous processing.
Fault tolerance.
Authentication, authorization, encryption, rate limiting.
Logs, metrics and traces.
Explain why one approach was selected over another.
Suppose we are asked:
Design a URL shortener like Bitly.
Don't immediately draw 20 boxes.
Start with requirements.
Long URL
|
v
Short URLExample:
https://example.com/very/long/path
|
v
abc123Opening:
https://short.ly/abc123should redirect to the original URL.
User
|
v
Load Balancer
|
v
Application Server
|
+-------> Cache
|
+-------> DatabaseThen we ask:
Notice that System Design starts with questions, not technology names.
These are related but different.
Focuses on:
Services
Databases
Caches
Queues
Networks
Scaling
Availability
ArchitectureExample:
Client
↓
Load Balancer
↓
API Servers
↓
Redis
↓
PostgreSQLFocuses more on:
Classes
Interfaces
Objects
Methods
Design patterns
Code structureExample:
class PaymentService {
processPayment()
refundPayment()
}This course primarily focuses on System Design / High-Level Design, while we will also connect architecture decisions to implementation where useful.
For each major case study, we will use a consistent framework:
1. Requirements
↓
2. Scale estimation
↓
3. APIs
↓
4. Data model
↓
5. Basic architecture
↓
6. Database choice
↓
7. Caching
↓
8. Scaling
↓
9. Reliability
↓
10. Security
↓
11. Observability
↓
12. Bottlenecks
↓
13. Trade-offs
↓
14. Final architectureThis framework will eventually become your interview methodology.
Bad:
Let's use Kafka, Redis, Kubernetes and MongoDB.
Better:
What problem are we solving?
Then select technologies based on requirements.
Microservices are not automatically better.
A small application might be better served by:
Modular Monolithrather than:
20 MicroservicesArchitecture should follow requirements.
A design for:
1,000 usersis different from a design for:
100 million usersAlways estimate workload.
Ask:
What happens if this component goes down?
For every important component.
If multiple copies of data exist, ask:
How do these copies stay consistent?
A system-design diagram is not enough.
You must explain:
A system-design interview is not simply:
Draw the most complicated architecture possible.
It is a conversation about engineering decisions.
A strong design discussion looks like:
Requirement
↓
Constraint
↓
Design choice
↓
Trade-off
↓
ResultFor example:
We expect significantly more reads than writes, so we can use read replicas to scale reads. This introduces replication lag, so operations requiring the latest value should use the primary.
That is system-design reasoning.
By the advanced stage, given:
Design a global video-sharing platform.
You should naturally think:
Requirements
↓
Traffic estimation
↓
Upload architecture
↓
Object storage
↓
Video transcoding
↓
Metadata database
↓
CDN
↓
Caching
↓
Queues
↓
Search
↓
Recommendations
↓
Multi-region architecture
↓
Reliability
↓
Observability
↓
Security
↓
Cost & trade-offsYou will not memorize this architecture.
You will derive it from the requirements.
The most important concepts from this chapter are:
Designing how system components interact to satisfy functional and non-functional requirements.
Ability to handle increasing workload.
Ability to remain accessible.
Ability to consistently behave correctly.
Time required to complete an operation.
Amount of work processed per unit of time.
Maximum workload a system can handle under defined constraints.
Ability to preserve successfully stored data.
How data is observed across replicas and operations.
Ability to continue operating despite failures.
Adding more machines.
Increasing machine capacity.
Requests can be handled independently by different servers.
A system whose components operate across multiple machines.
Remember this:
SYSTEM DESIGN
|
+--------------+--------------+
| | |
v v v
REQUIREMENTS SCALE CONSTRAINTS
| | |
+--------------+--------------+
|
v
ARCHITECTURE
|
+--------------+--------------+
| | |
v v v
COMPUTE STORAGE NETWORK
| | |
+--------------+--------------+
|
v
SCALABILITY
|
v
RELIABILITY
|
v
SECURITY
|
v
OBSERVABILITY
|
v
TRADE-OFFSThe goal of this course is to make this reasoning process natural.
Design this system:
A simple URL shortener supporting 1 million users.
Start with:
Requirements
↓
Traffic
↓
Architecture
↓
Database
↓
CacheDo not worry about advanced technologies yet.
We will follow one request from beginning to end:
User types:
https://example.com
↓
Browser
↓
DNS
↓
IP Address
↓
TCP
↓
TLS
↓
HTTP Request
↓
Load Balancer
↓
Web/Application Server
↓
Database
↓
HTTP Response
↓
Browser
↓
UserWe will build the foundation needed to understand every architecture that comes later in this course.
Mark it as complete to track your mastery.