Before designing large distributed systems, you need to understand what happens when a user performs something as simple as:
https://example.comA modern web request may pass through many layers:
User
↓
Browser
↓
DNS
↓
Internet / Network
↓
TCP
↓
TLS
↓
HTTP
↓
CDN / Reverse Proxy
↓
Load Balancer
↓
Application Server
↓
Cache / Database
↓
Application Server
↓
HTTP Response
↓
Browser
↓
UserEvery component exists for a reason.
Later in this course, when we design systems such as WhatsApp, YouTube, Uber, Instagram or Amazon, these same concepts will appear repeatedly.
Imagine that you type:
https://www.example.com/productsinto your browser and press Enter.
At a high level:
Browser
|
| 1. Find the server
v
DNS
|
| 2. Return IP address
v
Server IP
|
| 3. Establish connection
v
TCP
|
| 4. Secure connection
v
TLS
|
| 5. Send HTTP request
v
Web infrastructure
|
| 6. Route request
v
Application Server
|
| 7. Execute business logic
v
Database / Cache
|
| 8. Return data
v
Application Server
|
| 9. HTTP response
v
BrowserWe will now break this down one step at a time.
The two most basic concepts are:
The client is the software requesting a service.
Examples:
For a website:
Browser = ClientA server is a system that receives requests and provides responses or services.
Example:
Browser
|
| Request
v
Server
|
| Response
v
BrowserA server could:
The basic web interaction is:
Client
|
| Request
v
Server
|
| Response
v
ClientFor example:
GET /productsThe server might respond with:
{
"products": [
{
"id": 1,
"name": "Laptop"
}
]
}This simple model is the foundation of web applications.
A URL identifies a resource on the network.
Example:
https://www.example.com/products?id=10It can be broken into pieces:
https://
|
+-- Protocol / scheme
www.example.com
|
+-- Host / domain
/products
|
+-- Path
?id=10
|
+-- Query parametersA more complete URL can contain:
https://user:password@example.com:443/products?id=10#reviewsConceptually:
scheme://host:port/path?query#fragmentImportant parts:
| Part | Example | Purpose |
|---|---|---|
| Scheme | https |
Communication protocol |
| Host | example.com |
Destination |
| Port | 443 |
Network service endpoint |
| Path | /products |
Resource/path |
| Query | ?id=10 |
Additional parameters |
| Fragment | #reviews |
Client-side document location |
Humans prefer names:
example.comComputers communicate using network addresses such as:
93.184.216.34We therefore need a mechanism to translate:
example.com
↓
IP addressThat mechanism is DNS.
DNS stands for:
Domain Name System
Its primary role is translating domain names into IP addresses.
Conceptually:
Browser
|
| What is the IP of example.com?
v
DNS
|
| 93.184.216.34
v
BrowserThe browser can then communicate with the destination.
DNS is much more than a simple lookup table. It is a distributed hierarchical system.
We will study DNS deeply in Chapter 03.
For now, remember:
DNS helps clients locate services using human-readable domain names.
An IP address identifies a network endpoint.
IPv4 example:
192.168.1.10Public servers can have publicly reachable addresses.
IPv6 uses a larger address space, for example:
2001:db8::1The important mental model is:
Domain
↓ DNS
IP address
↓
Network communicationA machine can run multiple network services.
For example:
Server
|
+-- Port 22 → SSH
|
+-- Port 80 → HTTP
|
+-- Port 443 → HTTPS
|
+-- Port 5432 → PostgreSQLA port identifies the service endpoint on a host.
A network destination is therefore conceptually:
IP address + portFor example:
93.184.216.34:443means:
Host: 93.184.216.34
Port: 443HTTP stands for:
Hypertext Transfer Protocol
It defines how clients and servers communicate application-level web messages.
Example request:
GET /products HTTP/1.1
Host: example.com
Accept: application/jsonExample response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"products": []
}HTTP is request/response oriented.
Common methods include:
| Method | Typical purpose |
|---|---|
| GET | Retrieve data |
| POST | Create/process data |
| PUT | Replace a resource |
| PATCH | Partially update a resource |
| DELETE | Delete a resource |
Example:
GET /users/10means:
Retrieve user 10.
Another:
POST /userscould mean:
Create a new user.
The server communicates the result using a status code.
Common examples:
| Code | Meaning |
|---|---|
| 200 | Successful request |
| 201 | Resource created |
| 204 | Successful request with no response body |
| 301 | Permanent redirect |
| 302 | Temporary redirect |
| 400 | Bad request |
| 401 | Authentication required/failed |
| 403 | Forbidden |
| 404 | Resource not found |
| 409 | Conflict |
| 429 | Too many requests |
| 500 | Internal server error |
| 502 | Bad gateway |
| 503 | Service unavailable |
| 504 | Gateway timeout |
A useful classification:
1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client-side/request problem
5xx → Server-side problemHTTPS means HTTP communication protected using TLS.
Conceptually:
HTTP
+
TLS
=
HTTPSWithout encryption, sensitive data could potentially be exposed while traveling across the network.
HTTPS provides important security properties such as:
A simplified flow:
Browser
|
| TLS handshake
v
Server
|
| Secure connection established
v
Encrypted HTTP communicationWe will study TLS and security much more deeply later.
TCP stands for:
Transmission Control Protocol
For many traditional web connections, TCP provides reliable, ordered delivery between endpoints.
Conceptually:
Application
↓
HTTP
↓
TLS
↓
TCP
↓
IP
↓
NetworkTCP handles things such as:
You do not normally implement these mechanisms yourself when building a typical web application.
A simplified TCP connection establishment uses a three-step handshake:
Client Server
SYN -------------------->
<------------------ SYN-ACK
ACK -------------------->After the connection is established, application data can flow.
The exact behavior depends on the networking stack and protocol version, but the important beginner mental model is:
TCP establishes a reliable connection between endpoints.
A useful simplified model is:
+----------------------+
| Application |
| HTTP |
+----------------------+
| Security |
| TLS |
+----------------------+
| Transport |
| TCP |
+----------------------+
| Internet |
| IP |
+----------------------+
| Link / Physical |
| Ethernet / Wi-Fi |
+----------------------+Each layer has a responsibility.
This layered architecture is important because system-design problems often involve bottlenecks or failures at different layers.
Let's now connect everything.
Suppose:
https://example.com/productsThe browser determines:
Scheme = HTTPS
Host = example.com
Path = /productsIt performs DNS resolution.
example.com
|
v
DNS
|
v
IP addressThe client establishes the required network connection.
For traditional HTTPS over TCP:
Browser
↓
TCP connectionThe client and server establish a secure TLS session.
Browser ←→ Server
TLSThe browser sends something conceptually like:
GET /products HTTP/1.1
Host: example.comThe request may first reach:
CDN
↓
Reverse Proxy
↓
Load BalancerNot every application uses every component.
For example:
Load Balancer
/ | \
v v v
App1 App2 App3The application may:
Request
↓
Authentication
↓
Business logic
↓
Cache
↓
DatabaseFor example:
Database
|
| Product records
v
ApplicationHTTP/1.1 200 OK
Content-Type: application/jsonApplication
↓
Load Balancer
↓
Network
↓
BrowserFor HTML:
HTML
↓
CSS
↓
JavaScript
↓
Rendered pageFor an API request:
JSON
↓
Frontend JavaScript
↓
UI updateThe complete simplified picture:
USER
|
v
BROWSER
|
v
DNS
|
v
IP ADDRESS
|
v
TCP
|
v
TLS
|
v
HTTP
|
v
+-------------+
| CDN |
+------+------+
|
v
+------------------+
| Reverse Proxy / |
| Load Balancer |
+--------+---------+
|
+------------+------------+
| | |
v v v
Server A Server B Server C
| | |
+------------+------------+
|
+------+------+
| |
v v
CACHE DATABASE
| |
+------+------+
|
v
APPLICATION
|
v
RESPONSE
|
v
BROWSER
|
v
USERThis diagram will become extremely familiar throughout the course.
A web server accepts HTTP requests and returns responses.
Examples include:
A web server can handle:
An application server executes application/business logic.
For example:
GET /orders/100The application may:
1. Authenticate user
2. Check authorization
3. Query order
4. Fetch payment information
5. Construct response
6. Return JSONThe architecture might look like:
Client
|
v
Web Server / Proxy
|
v
Application Server
|
v
DatabaseModern frameworks can blur the traditional distinction between web server and application server, but the conceptual separation remains useful.
A reverse proxy sits in front of application servers.
Client
|
v
Reverse Proxy
|
+------> App A
|
+------> App B
|
+------> App CIt can provide:
Examples of reverse-proxy technologies include Nginx and Envoy.
We will study reverse proxies and load balancing later.
A load balancer distributes requests across multiple servers.
Without one:
Users
|
v
ServerWith one:
Users
|
v
Load Balancer
|
+----> Server A
|
+----> Server B
|
+----> Server CBenefits include:
Load balancing becomes a dedicated topic later.
A cache stores frequently accessed data closer to the application or user.
Example:
Application
|
v
Cache
|
| Cache miss
v
DatabaseIf the requested data is already cached:
Application
|
v
Cache
|
v
ResponseThis can reduce:
Caching will receive two dedicated chapters later.
The database stores persistent application data.
Example:
Application
|
v
Database
|
+-- Users
+-- Orders
+-- Products
+-- PaymentsDatabases are often among the most important components in system design because data access patterns strongly influence architecture.
We will later study:
Not every operation needs to happen during the user's request.
User
|
v
API
|
v
Process
|
v
ResponseThe user waits for the operation.
User
|
v
API
|
v
Queue
|
v
Immediate response
Later:
Queue
|
v
Worker
|
v
ProcessingExample:
A user uploads an image.
Instead of making them wait for every thumbnail and transformation:
Upload
↓
Store image
↓
Queue processing job
↓
Return responseWorkers can process the image asynchronously.
Messaging and event-driven architecture will be covered later.
Content that can be served without executing user-specific business logic.
Examples:
These are excellent candidates for CDN delivery.
Content generated based on:
Example:
GET /my/ordersThe response depends on the authenticated user.
A simplified architecture:
Static:
User → CDN → Image/CSS/JS
Dynamic:
User → Load Balancer → Application → DatabaseReal systems often combine both.
The browser often handles:
The backend often handles:
Example:
Browser
|
| POST /orders
v
Backend
|
+--> Validate request
|
+--> Check inventory
|
+--> Create order
|
+--> Store data
|
v
ResponseA modern application commonly exposes APIs.
Example:
GET /users/123
POST /users
PATCH /users/123
DELETE /users/123The frontend can communicate with these endpoints.
React / Next.js
|
| HTTPS
v
Backend API
|
v
DatabaseAPI design becomes an important part of system design because poor APIs can create scaling, security and usability problems.
Consider:
GET /homeIt may look like one request to the user.
Internally:
Browser
|
v
API
|
+--> User Service
|
+--> Recommendation Service
|
+--> Product Service
|
+--> Notification Service
|
+--> Cache
|
+--> DatabaseTherefore:
One external request does not necessarily mean one internal operation.
This becomes increasingly important as we move toward microservices and distributed systems.
Suppose a request requires:
DNS = 10 ms
Network = 20 ms
Database = 30 ms
Service A = 20 ms
Service B = 30 msA simplified sequential total is:
10 + 20 + 30 + 20 + 30
= 110 msIf service calls happen sequentially, latency can accumulate.
If independent calls can happen concurrently, the critical path may be closer to the slowest parallel operation rather than the sum.
This is why architecture and request flow matter.
Now consider where a request can fail:
Browser
|
X DNS failure
|
v
DNS
|
X Network failure
|
v
Server
|
X Application failure
|
v
Cache
|
X Cache unavailable
|
v
Database
|
X Database failureSystem design is partly about asking:
What happens when each dependency fails?
For example:
Cache fails
↓
Can application query database?or:
Database replica fails
↓
Can another replica serve reads?Later we will turn these questions into formal reliability patterns.
Imagine an e-commerce request:
GET /products/100Possible flow:
Browser
|
v
DNS
|
v
CDN / Load Balancer
|
v
Product API
|
v
Redis Cache
|
+---- HIT ----> Return product
|
+---- MISS
|
v
PostgreSQL
|
v
Product API
|
v
Redis SET
|
v
BrowserThis architecture already uses several system-design concepts:
We haven't yet studied these components deeply. We are building the mental model first.
DNS helps locate services, but DNS itself does not carry the application's entire communication.
DNS → Find destination
HTTP → Application communicationNormally:
Browser
↓
Backend API
↓
Databasenot:
Browser
↓
DatabaseDirect database exposure creates serious architectural and security problems.
A useful simplified model is:
HTTP
+
TLS security
=
HTTPSHTTPS is HTTP communication protected by TLS.
A tiny application may not need one.
Architecture should match requirements.
A cache generally exists to speed access to data whose authoritative source is elsewhere.
A common model is:
Database = persistent source
Cache = fast temporary copySpecific architectures can differ, but this is a useful starting mental model.
A strong answer should mention, at an appropriate level:
URL parsing
→ DNS
→ network connection
→ TLS for HTTPS
→ HTTP request
→ server-side processing
→ response
→ browser renderingA system that maps domain names to network destinations such as IP addresses.
HTTPS is HTTP communication protected by TLS.
A component that distributes incoming traffic among backend instances or services.
To reduce latency and/or reduce load on slower or more expensive underlying systems.
Because business logic, authorization, validation and security boundaries belong in application/backend services rather than exposing the database directly to untrusted clients.
With multiple healthy instances behind a suitable load-balancing architecture, traffic can be routed to other instances.
Explain this architecture:
User
↓
Load Balancer
↓
Server
↓
DatabaseWhat does each component do?
Add caching:
User
↓
Load Balancer
↓
Server
↓
?
↓
DatabaseWhere would you place the cache and why?
Suppose you have three application servers:
Server A
Server B
Server CWhat component would you put in front of them?
Why?
A website is slow because every request performs an expensive database query.
Give three possible approaches to investigate or improve the system.
Explain this request from beginning to end:
https://shop.example.com/products/123Your explanation should include:
Design a very small e-commerce architecture.
Requirements:
Start with:
Users
|
v
??????
|
v
??????
|
v
??????Your task is to identify:
Don't worry about advanced distributed systems yet.
You should now understand the basic journey:
User
↓
Browser
↓
DNS
↓
IP
↓
TCP
↓
TLS
↓
HTTP
↓
CDN / Reverse Proxy / Load Balancer
↓
Application Server
↓
Cache / Database
↓
Application Server
↓
HTTP Response
↓
Browser
↓
UserThe most important concepts are:
The key mental model is:
A web application is not one box. It is a collection of components communicating across multiple layers.
System Design is the discipline of deciding how those components should interact as requirements, traffic, data and reliability requirements grow.
We will go deeper into the network itself:
IP
↓
Ports
↓
Packets
↓
TCP
↓
UDP
↓
Routing
↓
NAT
↓
LAN/WAN
↓
Bandwidth
↓
Latency
↓
Network failures
↓
Network bottlenecksThis will give us the networking foundation needed before going deeper into DNS, HTTP, load balancing and distributed systems.
Mark it as complete to track your mastery.