How a Request Travels Through a System

One URL, several possible stopping points#

A user opens https://engineeringfoundry.com/system-design. The browser has a hostname, not an application-server address. Before any business logic runs, the client may resolve DNS, establish transport and TLS, reuse an existing connection, and reach an edge cache. A cache hit may return without touching the origin at all.

From hostname to a secure connection#

DNS maps the hostname to a network destination. The client then establishes a transport connection or reuses one. For HTTPS, TLS authenticates the server and protects data in transit. Connection reuse matters because repeatedly paying setup cost adds latency.

The request can reach an edge location before the origin. Cacheable assets may terminate there. On a miss, the edge forwards toward a load balancer, which selects a healthy backend without exposing instance topology to the client.

Inside the origin#

The application server parses the request, authenticates the caller, validates input, runs business logic, and accesses a cache or database only if required. It serializes the response, may compress an appropriate representation, and sends it back through the intermediaries.

Build a latency budget before optimizing#