Backend · MySQL

What Actually Happens When You Type a Domain Name: DNS, Nginx, Clusters, and CDN

By 东风破_ · Aug 27, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Many developers can build an API but can't trace a request end-to-end through production infrastructure. This walkthrough connects DNS, reverse proxying, load balancing, static asset offloading, and CDN caching into one coherent chain — the minimum mental model needed to reason about a live system's bottlenecks, failure points, and cost drivers.

Summary

Typing a domain name triggers a chain that most developers learn in fragments. DNS resolves the name to an IP; a TCP (and possibly TLS) connection forms; an entry-point layer — typically Nginx or a cloud load balancer — receives the request and forwards it to one of many identical backend servers running the application. The backend queries a shared database for dynamic data, while static assets like images, JS, and CSS are served from a separate object store (OSS) and distributed through a CDN so users worldwide hit a nearby cache.

The article builds this path step by step, starting from a single-server Nest.js + MySQL setup and scaling it out. It clarifies why Nginx is a reverse proxy, not a business-logic server; why server clusters all run the same code against a shared database; and why avatar URLs often point to a different domain — because static files are stripped out of the application path entirely.

A three-layer mental model emerges: business data (MySQL), business logic (Nest.js), and network/infrastructure (DNS, Nginx, OSS, CDN). The final section ties it back to database design, showing why an `avatar` table stores only metadata while the actual bytes live in object storage and get delivered by CDN.

Takeaways

— DNS is a hierarchical lookup system that maps a domain to an IP; browsers check local caches first, then query resolvers that may walk root, TLD, and authoritative servers.

— After DNS resolution, a TCP connection (and TLS for HTTPS) is established before any HTTP request is sent.

— The IP a user reaches is rarely a backend application server — it's an entry point like Nginx or a cloud load balancer.

— Nginx acts as a reverse proxy: it receives requests on behalf of backend servers, forwards them, and returns responses, hiding internal server addresses from users.

— Load balancing distributes incoming requests across multiple identical backend servers so no single machine is overwhelmed.

— All servers in a cluster run the same application code and share a common database, so any instance can handle any request.

— Static resources (images, CSS, JS, fonts) carry no business logic and are offloaded to object storage (OSS) to avoid consuming application server bandwidth.

— A CDN caches static files on edge nodes worldwide; after the first fetch from origin, nearby users get cached copies, cutting latency and origin load.

— Dynamic requests (API calls) flow through Nginx → backend → database; static requests go browser → CDN → OSS, often to a completely different domain.

— Database tables for uploaded files store only metadata (filename, size, owner); the binary lives in OSS, and CDN handles delivery.

Conclusions

The article's strength is sequencing: it starts with a single-server mental model and adds each piece only when the previous setup breaks under scale, which mirrors how real architectures evolve.

Treating DNS, Nginx, OSS, and CDN as answers to six concrete questions ('Where should I go?', 'Who should handle this request?', 'Where are the actual files?') turns a fog of acronyms into a checklist a developer can debug against.

The three-layer split — data, logic, infrastructure — is a useful classification for onboarding: it prevents beginners from conflating Nginx config with business code or CDN caching with database queries.

The explicit connection back to database schema design (why an `avatar` table stores only metadata) closes a common gap between backend developers who design tables and those who operate deployment pipelines.

Concepts & terms

DNS (Domain Name System)

A hierarchical, distributed naming system that translates human-readable domain names (e.g., juejin.cn) into machine-routable IP addresses. Queries cascade through browser cache, OS cache, resolvers, root servers, TLD servers, and authoritative nameservers until an answer is found.

Reverse Proxy

A server that sits in front of backend application servers, receives client requests, forwards them to the appropriate backend, and returns the response. Clients see only the proxy's address; the real servers remain hidden. Nginx is a common implementation.

Load Balancing

The practice of distributing incoming network traffic across multiple backend servers running the same application, preventing any single server from becoming a bottleneck or single point of failure.

OSS (Object Storage Service)

Cloud-based storage for unstructured data like images, videos, and static files. Examples include AWS S3, Alibaba Cloud OSS, and Tencent Cloud COS. The application database stores file metadata; OSS stores the actual binary blobs.

CDN (Content Delivery Network)

A geographically distributed network of caching servers (edge nodes) that serve static content to users from the nearest node. After an initial fetch from the origin (e.g., OSS), subsequent requests are served from cache, reducing latency and origin load.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗