Follow one request from browser to storage
A user opens an order-tracking page. Before discussing microservices, trace the dependencies that can make this request slow or unavailable:
Browser -> DNS resolver -> edge/CDN -> reverse proxy/load balancer
-> application -> connection pool -> database
DNS translates a name into a destination, subject to resolver caches and TTLs. A TCP connection establishes an ordered byte stream. TLS authenticates the peer and protects transport. HTTP expresses request and response semantics. The application still authenticates the caller and authorizes access to this particular order. Transport encryption does not grant permission.
A connection can be reused, so each request need not repeat DNS, TCP and TLS setup. Distinguish cold-start connection latency from steady-state request latency. A tiny response over a new distant connection may be slower than a larger response over an existing local one.
TCP, UDP, HTTP/2 and HTTP/3
TCP handles retransmission and ordering; applications must frame messages on its byte stream. UDP datagrams do not provide that reliability by themselves. QUIC adds transport features over UDP, and HTTP/3 runs over QUIC. Do not claim UDP applications are inherently unreliable: their protocol can add reliability.
HTTP/2 multiplexes streams on a connection, but TCP packet loss can delay streams sharing that connection. HTTP/3 reduces cross-stream transport head-of-line blocking; one stream can still block on its own missing data. Compression, connection reuse, geography and server work all matter; a protocol upgrade cannot repair an unindexed query.
Forward proxy vs reverse proxy
| Component | Represents | Example decision |
|---|---|---|
| Forward proxy | Clients reaching upstream servers | Corporate outbound traffic policy |
| Reverse proxy | Servers serving incoming clients | Terminate TLS and route /orders |
| Load balancer | A healthy pool of destinations | Spread requests across app instances |
| API gateway | An API boundary with policy | Authenticate, quota and version routing |
One product may perform several roles. In an interview, describe responsibilities rather than adding a separate box for each name. Only trust forwarded-client-IP headers from known proxy hops; an attacker can supply their own header to an unguarded origin.
Proxy placement and trust
An explicitly configured forward proxy receives a client's outbound traffic. A transparent proxy can intercept traffic through network configuration. A reverse proxy receives requests addressed to a service and selects an origin. These placements affect whose policy is enforced and which address the destination sees.
HTTP proxies understand HTTP requests; SOCKS proxies relay connections more generally. A proxy operator may observe destinations, timing and unencrypted traffic. Changing the visible IP is not a privacy guarantee, and a TLS-terminating proxy becomes part of the trust boundary. Authenticate administrative access, restrict outbound destinations and avoid treating a public proxy as a safe credential path.
CDN: cache close to the reader
For versioned assets, use a content hash in the filename and a long freshness lifetime. For frequently changing public content, use shorter freshness, validators and an explicit invalidation strategy. An edge miss may fetch through a regional cache or origin shield before reaching the application.
A cache key must include every input that changes the response. Forgetting language, tenant or authorization context can serve another user's data. Personalized pages should not accidentally enter a shared public cache. Vary can describe representation dimensions, but unbounded dimensions destroy hit rate.
HTTP freshness and validation are different: a fresh response can be reused immediately; a stale response may be revalidated with ETag/If-None-Match and receive a 304. no-cache means validate before reuse, while no-store tells caches not to store the response.
Worked example: origin load
Suppose a public asset receives 20,000 requests/second and the edge hit ratio is 95%. The simplified origin request rate is 1,000/second. If a simultaneous purge drops hits to 50%, origin load becomes 10,000/second. Provisioning only for warm-cache averages creates a failure during deployments.
Use request coalescing, origin shielding, staggered expiry and a bounded stale-serving policy where correctness permits it. A checkout confirmation is a poor candidate for indiscriminate stale serving.
Routing and failure boundaries
DNS failover is limited by caching and client behavior. Anycast routes an address through the network; it is not application-level session management. Geo-routing must consider residency constraints and unhealthy regions, not just nearest distance. Health checks should detect inability to serve traffic without making every app depend on an overloaded shared service.
A connection pool is also a queue. If 100 application instances each open 100 DB connections, the database can face 10,000 connections. Bound total concurrency, size pools across the fleet and set deadlines for waiting. A proxy can multiplex connections but cannot manufacture database CPU.
Interview exercise
Design image delivery for a learning platform. Specify upload authorization, object storage, content hashes, resizing, CDN key, private-media access, invalidation, origin overload and regional failure. Explain why you would not route every image through the application.
Next: load balancing, API contracts, and real-time communication.