What Actually Happens When You Type a Domain Name: DNS, Nginx, Clusters, and CDN
theme: github
In the previous two articles, we've been designing a blog system from the database perspective:
user
post
comment
tag
file
...
But finishing the database design doesn't mean users can actually use the website.
A truly live web system still needs to solve another problem:
When a user types
juejin.cninto the browser, how does their request actually reach our backend program?
This question involves:
DNS
IP
TCP
Nginx
Reverse Proxy
Load Balancing
Server Cluster
OSS
Static Resource Server
CDN
These terms are very confusing when they first appear together.
This article connects them into one complete chain.
1. First, imagine the simplest web project
Suppose we write a blog backend using Nest.js:
Nest.js
Running on a server:
User API
Post API
Like API
Comment API
The database stores:
Users
Posts
Comments
Like relationships
If the project is small, the simplest case might be:
User
↓
One server
↓
Nest.js
↓
MySQL
But an online service like Juejin can't rely on just one server.
Why?
Because if there are simultaneously:
10 users
1000 users
100000 users
A single server's CPU, memory, and connection count all have limits.
And:
If that server goes down, the entire website is gone.
So large systems usually evolve into:
Many backend servers
2. But users access a domain name, not server code
Users type:
juejin.cn
But when computers actually communicate over the network, they need:
IP address
So the first question is:
What IP does juejin.cn correspond to?
This process is handled by:
DNS
3. What exactly is DNS?
DNS:
Domain Name System
It can be understood as:
A lookup system between domain names and IP addresses.
For example:
juejin.cn
Eventually needs to resolve to something like:
xxx.xxx.xxx.xxx
Such an IP.
So:
Domain name
→ DNS query
→ IP
4. DNS queries don't start from scratch every time
When the browser is about to access a domain name, it checks caches first.
For example, it may check in order:
Browser DNS cache
OS DNS cache
Local network configuration
DNS resolver
If it already knows the answer, there's no need to query again.
If not found locally, it sends a query to the configured DNS resolution service.
The subsequent DNS system will continue to find, as needed:
Root DNS
Top-level domain DNS
Authoritative DNS
And other information, eventually obtaining the address corresponding to the target domain.
So simply understanding DNS as:
Finding the corresponding server IP from a domain name.
Is enough to build a first-level understanding.
5. What happens after getting the IP?
Once the browser knows the target IP, it can attempt to establish a network connection with the server.
In common TCP-based HTTP/1.1 or HTTP/2 scenarios, this involves TCP connection establishment.
The classic TCP connection establishment process is:
Three-way handshake.
So we can roughly understand:
juejin.cn
↓
DNS
↓
IP
↓
Establish network connection
↓
Send HTTP request
If using HTTPS, it also involves:
TLS
Establishing a secure connection.
6. Is this IP definitely the Nest.js server?
Not necessarily.
Large websites usually don't directly expose:
Nest Server A
Nest Server B
Nest Server C
And let users choose by themselves.
Users are more likely to first access:
The entry layer.
This entry layer may use:
Nginx
Or a cloud provider's:
Load Balancer
7. Why do we need many backend servers?
Suppose we now have:
Server A
Server B
Server C
Server D
Each machine is deployed with the same Nest.js application.
That is:
Server A
can handle GET /posts
Server B
can also handle GET /posts
Server C
can also handle GET /posts
Now many users arrive simultaneously.
We can't stuff all of them into Server A.
We want:
Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A
...
So we need a role that:
Helps distribute requests.
This is load balancing.
8. What does Nginx do here?
Nginx can be placed in front of the backend server cluster:
Nginx
Server A
Server B
Server C
Server D
Users don't know how many business servers are behind.
Users only access:
juejin.cn
After Nginx receives the request, it decides:
Which backend server to hand this request to.
For example:
GET /api/posts
Might be forwarded to:
Server B
Next time:
POST /api/comment
Might be forwarded to:
Server C
9. Why is it called "reverse proxy"?
First, look at the world from the user's perspective.
Users think they are accessing:
juejin.cn
But in reality, the ones actually handling the business might be:
10.0.0.11:3000
10.0.0.12:3000
10.0.0.13:3000
These servers are hidden behind Nginx.
Nginx:
Receives requests on behalf of servers
Then forwards requests to the real servers
Finally returns results to the user
So:
Nginx acts as a proxy for the backend servers on the server side.
This is:
Reverse proxy
10. What's the relationship between reverse proxy and load balancing?
The two are not exactly the same concept.
Reverse proxy emphasizes:
User requests first go to the proxy server, and the proxy server then accesses the real backend.
Load balancing emphasizes:
When there are multiple servers behind, distributing traffic reasonably.
So Nginx can:
Only do proxying
Or it can:
Proxying + Load balancing
For example:
User
↓
Nginx
├── Server A
├── Server B
└── Server C
Here both things exist simultaneously.
11. Does Nginx handle Nest.js business logic itself?
Usually not.
For example:
Register user
Create post
Write comment
Check JWT
Query database
These logics are still handled by:
Nest.js
Nginx is mainly responsible for entry-layer work, such as:
Reverse proxy
Load balancing
TLS termination
Static resource serving
Request limiting
Caching
So don't confuse Nginx with the business backend.
12. Why do server clusters all run the same program?
Suppose the project is packaged and deployed simultaneously to:
Server A
Server B
Server C
They run the same Nest.js service.
So any one of them can handle:
GET /posts/100
The real data is usually in a shared database, cache, or other infrastructure.
For example:
Server A
Server B
Server C
↓
MySQL
So a request being assigned to any business server doesn't mean each server has completely different data.
13. Where is the database usually placed?
Backend business and database are generally deployed in the server environment.
There may be multiple application servers:
Nest A
Nest B
Nest C
And the database might be:
MySQL master-slave
Database cluster
Cloud database
Sharded database
The specific architecture changes continuously with scale.
But for beginners, first understand:
Request
→ Backend application
→ Database
Is sufficient.
The database is responsible for:
Users
Posts
Comments
Likes
Bookmarks
Tags
Such structured business data.
14. What about avatars and article images?
Here comes another very important question.
Suppose an avatar size is:
200 KB
An article has:
20 images
If all images go through:
Request business backend
→ Nest.js
→ Find file from disk
→ Return
A lot of bandwidth and connections will be occupied by static resources.
And images themselves have no complex business logic at all.
So large websites usually separate:
Images
CSS
JavaScript
Fonts
Videos
Attachments
Such resources from the core business service.
15. What are static resources?
Static resources can be simply understood as:
The server doesn't need to dynamically compute content based on business logic; it just returns the file directly.
For example:
logo.png
avatar.webp
main.js
style.css
font.woff2
They are completely different from:
POST /login
POST /comment
GET /api/user
These kinds of requests.
The latter need to execute programs.
The former, most of the time, is just:
Giving you the file.
16. Why are avatar links often not the main site domain?
You'll notice that image URLs on many large websites are not:
juejin.cn/avatar/xxx
But come from a separate static resource domain.
For example:
xxx.byteacctimg.com/...
This is a very common design.
Because:
juejin.cn
Mainly handles business access.
While:
Static resource domain
Specifically provides:
Images
Avatars
JS
CSS
And other resources.
17. What is OSS?
For example, a user uploads an avatar:
avatar.png
After the backend receives the upload request, it can save the file to:
Alibaba Cloud OSS
AWS S3
Tencent Cloud COS
These types of services are collectively called:
Object storage.
The database might only save:
filename
size
mimetype
userId
objectKey
While the actual:
Image binary
Is stored in OSS.
So the database is responsible for:
Whose file is it?
OSS is responsible for:
Where is the file itself placed?
Responsibilities are very clear.
18. What is CDN?
If all static resources only exist on one server in Beijing:
Beijing static server
Beijing users might access it quickly.
But a user in the US would have to traverse a very long network distance to fetch:
avatar.webp
Which could be very slow.
CDN stands for:
Content Delivery Network
It deploys a large number of edge nodes in different regions.
For example:
Beijing
Shanghai
Guangzhou
Tokyo
Singapore
Los Angeles
New York
...
So when users request static resources, they can get them from a node as close to them as possible.
19. How can CDN be understood?
Suppose the original image is saved in:
OSS
A user's first request:
/avatar/abc.webp
A certain CDN node doesn't have it locally.
It might go to the origin server to fetch it:
CDN
↓
OSS
Then cache it.
The next batch of nearby users continuing to request:
/avatar/abc.webp
Can directly:
User
↓
Nearby CDN
↓
Return image
No need to access the original storage every time.
Thus:
Latency reduced
Origin server pressure reduced
Bandwidth utilization more reasonable
20. Dynamic requests and static requests should be understood separately
Now accessing an article page.
The page might need:
Article body
Author info
Like count
Comment data
These are dynamic business data.
They might go through:
Browser
↓
Nginx / Load Balancer
↓
Nest.js
↓
MySQL
But the page's:
Avatars
Article images
JS
CSS
Might directly access:
CDN
So the same webpage might actually send requests to many different servers behind the scenes.
21. Now let's walk through juejin.cn again
Suppose a user opens:
https://juejin.cn
We can first understand it using the following simplified model.
Step 1: DNS
The browser needs to know:
juejin.cn
Which network address it corresponds to.
So it performs a DNS query.
Step 2: Establish connection
After getting the entry server address, establish a network connection.
HTTPS will also go through TLS secure connection related processes.
Step 3: Request reaches the entry layer
The request might first come to:
Load Balancer / Nginx
It itself is not responsible for the main business logic.
Step 4: Select a backend server
For example, the current cluster:
Nest A
Nest B
Nest C
The load balancer selects:
Nest B
To handle this request.
Step 5: Backend executes code
Nest.js:
Parse request
Verify user
Execute business logic
Query database
For example:
SELECT *
FROM post
WHERE id = 100;
Step 6: Return business data
Nest.js returns:
Article
Author
Comments
Like count
And other information.
Step 7: Browser continues to load static resources
The page might still have:
Avatars
Images
JavaScript
CSS
Fonts
These resources might be fetched from:
CDN
Finally, the browser combines them to present the complete webpage.
22. The whole system can be divided into three layers
Looking back now, you'll find it's actually not that messy.
Layer 1: Business data
MySQL
Responsible for:
Users
Posts
Likes
Comments
Tags
Layer 2: Business program
Nest.js
Responsible for:
Login
Authentication
Publish post
Post comment
Like
Query database
Layer 3: Network and infrastructure
DNS
Nginx
Load balancing
OSS
CDN
Responsible for:
Find server
Distribute traffic
Store files
Distribute static resources
This way, you won't mix all concepts together.
23. The easiest place to confuse Nginx and CDN
We can make a simple distinction.
Nginx
Leans more towards:
Request entry
Reverse proxy
Load balancing
Forwarding business requests
For example:
/api/posts
→ Nest Server B
CDN
Leans more towards:
Static content distribution
Nearby access
Caching
For example:
/avatar/a.webp
→ Nearby CDN node
So the core problems they solve are different.
24. DNS is not a "distributed database" either
DNS itself is indeed a globally distributed, hierarchical system, but when first learning, it's best not to simply memorize it as:
DNS is just a distributed database.
A more accurate understanding is:
DNS is a distributed, hierarchical naming system responsible for domain name resolution.
The problem it solves is:
Domain name
→ Network address and other DNS records
Not the business database's:
user
post
comment
25. Real large-scale systems are much more complex than this
Truly large internet applications may also have:
Redis
Message queue
Service registry
Gateway
Microservices
Database read-write separation
Database and table sharding
Container orchestration
Kubernetes
Multi-region deployment
WAF
Multi-level caching
But there's absolutely no need to learn all of them at once now.
First, get the most core chain clear:
Domain name
↓
DNS
↓
Server entry
↓
Reverse proxy / Load balancing
↓
Backend application
↓
Database
For static resources:
Browser
↓
CDN
↓
OSS / Static resource origin
This is already enough to establish a complete understanding of a web system.
26. Database knowledge and deployment knowledge are finally connected
Earlier we designed:
avatar
id
filename
mimetype
size
userId
Why does the database only save this information?
Now we can explain it.
Because:
Database
Responsible for file metadata
OSS
Responsible for actually saving images
CDN
Responsible for efficiently distributing images
For example:
avatar table
Might record:
userId = 7
filename = abc.webp
When actually accessing the avatar:
https://static.example.com/avatar/abc.webp
It might ultimately be returned by CDN.
So database design and server architecture are finally strung together.
Summary
When a user types a website address into the browser, behind the scenes it's far more than just:
The browser finds an HTML.
The actual system might involve:
DNS
Find the service entry
Nginx / Load Balancer
Receive and distribute requests
Nest.js
Execute backend business code
MySQL
Save business data
OSS
Save files like images
CDN
Distribute static resources to users nearby
Most importantly, don't mix these things into one concept.
You can remember them separately:
DNS
Where should I go?
Nginx / Load Balancer
Who should handle this request?
Nest.js
How to handle the specific business?
MySQL
Where is the business data stored?
OSS
Where are the actual files placed?
CDN
How to let users everywhere get static files faster?
Understanding these six questions, the basic outline of a complete web application from database design to online access is truly established.