System Design Networking Tutorial: DNS, HTTP, TLS, APIs, Proxies, and Load Balancers

Lesson 3 of the System Design learning track. Before choosing a database or cache, be able to narrate what happens when a user enters a URL. That request path is where latency, security boundaries, and availability behavior become concrete.

Prerequisite: finish Lesson 2: requirements and estimation. Return to the System Design learning track whenever you need the complete roadmap.

Learning outcome

You will be able to draw and review a basic request path: DNS resolves a name, a client establishes a secured connection, HTTP carries a request to a reverse proxy, and a load balancer selects a healthy application instance. You will also know which assumptions to make explicit in a design review.

Walk one request from name to response

1. DNS: the client resolves api.example.com to an address or alias through configured resolvers. DNS is a distributed naming system; caching and record TTLs influence how quickly changes are observed. The foundational model is described in RFC 1034.
2. Connection: the client connects to the selected address. With HTTPS, TLS authenticates the server and negotiates protected traffic before application data is exchanged. TLS 1.3 is specified in RFC 8446; do not treat a certificate as the entire security design.
3. HTTP: the client sends a method, target, headers, and optional body. The server returns a status code, headers, and optional content. HTTP’s common semantics are defined in RFC 9110.
4. Edge and application: a reverse proxy terminates or passes through the connection, applies routing and limits, selects an upstream, then returns the response.

Browser or mobile app
    |
    | 1. DNS: api.example.com -> edge address
    v
CDN / reverse proxy (TLS, WAF, request limits)
    |
    | 2. HTTP request, forwarded headers, route selection
    v
Load balancer
    |------------------|
    v                  v
API instance A     API instance B
    |                  |
    +------ data and dependency calls ------+

DNS is control-plane data, not instant failover magic

DNS gives a client a destination, but clients and resolvers may cache answers. In a design review, ask who controls the records, what names exist for public and private traffic, how health-based answers work, and how rollout or incident plans account for caching. A low TTL can increase lookup traffic without guaranteeing every client changes immediately. Keep application health checks and load balancing inside your serving path rather than relying on DNS alone for fast per-request decisions.

HTTP APIs need a contract at the edge

Define routes, methods, authentication, request-size limits, timeout behavior, and response semantics. HTTP is stateless at the protocol level; if your application uses sessions, idempotency keys, or affinity, make that a deliberate application or infrastructure choice. A 2xx response means the request succeeded at the HTTP layer; it does not prove every asynchronous side effect has completed. Design asynchronous APIs to communicate accepted work and a way to observe eventual completion.

TLS: terminate deliberately and preserve trust boundaries

TLS termination at an edge proxy is common. The hop from proxy to application then needs an explicit protection decision: private network controls may be sufficient in one threat model, while another requires TLS all the way to the workload. Protect private keys, automate certificate renewal, restrict supported protocols and ciphers through your platform’s maintained policy, and test the renewal path. Do not use forwarded client-IP or scheme headers unless they are set by a trusted proxy and the application is configured to trust that proxy.

Reverse proxies and load balancers solve different problems

A reverse proxy is an HTTP gateway: RFC 9110 describes a gateway as acting like an origin server to the client while forwarding inbound to one or more servers. It commonly centralizes TLS, routing, request limits, compression, and observability. A load balancer chooses among healthy targets. One product can perform both roles, but separating the responsibilities improves the design discussion.

Selection algorithms such as round robin, least connections, or weighted routing are only useful when target health is meaningful. Define readiness separately from liveness: a process can be alive but unable to serve because a required dependency is unavailable. Avoid sending new traffic to an instance until it is ready, and drain it before terminating it.

Worked example: a product API at 2,000 requests per second

From Lesson 2, suppose your peak estimate is 2,000 requests per second and a typical response takes 100 ms. Start with multiple stateless API instances behind a load balancer, then measure concurrency, CPU, connection counts, and downstream latency under load. The calculation is an initial hypothesis, not a server count. If one instance is removed, the remaining capacity must still meet the SLO; if a downstream service slows, bounded queues and deadlines prevent requests from piling up forever.

Common mistakes

• Calling DNS a load balancer without discussing caching, health, or client behavior.
• Trusting any incoming forwarded header and allowing a caller to spoof scheme or source IP.
• Using one timeout for every hop instead of budgeting the end-to-end deadline.
• Sending traffic to a process that has started but is not ready.
• Assuming retries are free; they increase load precisely when a dependency is unhealthy.

Validation and design-review steps

1. Draw the exact public-to-private request path and label every TLS termination point.
2. List DNS names, ownership, caching assumptions, and failure behavior.
3. State which component authenticates callers and which headers it adds or trusts.
4. Test readiness, draining, one-instance loss, an expired certificate alarm, and an unhealthy upstream.
5. Record request IDs and latency at the edge, load balancer, and application so a single request can be traced.

Production guidance

Keep application instances stateless where possible; externalize durable state. Set bounded timeouts and size limits at each boundary, log enough metadata to trace failures without logging credentials, and maintain runbooks for DNS, certificates, and traffic draining. Secure defaults at the edge reduce risk, but every service still needs authorization and input validation.

Next lesson

Lesson 4: Data modeling and storage choices. Next, you will turn access patterns into a schema and compare SQL, NoSQL, object storage, and search indexes without choosing a database by fashion.