System design · Day 3
Networking basics: DNS, CDNs, and load balancers
Follow traffic from a domain name to a healthy server and understand where latency, routing, and protection enter the path.
Before a service can scale, a request must find it. The network path is a sequence of lookups and routing decisions, each with a clear job.
DNS finds an address
DNS translates a domain such as example.com into an IP address or another name. Resolvers cache answers for their time-to-live, which reduces lookup cost but means routing changes take time to reach everyone.
After DNS, the client establishes a connection. HTTPS adds TLS so the client can verify the server and encrypt traffic. Connection reuse and modern HTTP versions reduce the cost of repeating these steps.
The edge serves and protects
A CDN stores cacheable content at locations near users. Images, scripts, downloads, and sometimes API responses travel a shorter distance and avoid the origin. This is the first cache layer before the application cache discussed on Day 6.
Edge services can also terminate TLS, filter malicious traffic, and apply rate limits. They protect the origin, but the application still needs authorization and input validation because perimeter controls are not product rules.
Load balancers choose a healthy instance
A load balancer distributes requests across application instances using algorithms such as round robin or least connections. Health checks remove unhealthy targets. Stateless application servers make this easy because any instance can handle the next request.
Session state should live in a shared store or a signed client token rather than one server's memory. Tomorrow, Day 4 defines the API contract those instances expose; later lessons add data, caches, and queues behind them.
“A request path is easier to design when every hop has one named responsibility.”