HTTP, APIs & networking

DNS and connection reuse reduce setup costs, but cached records can become stale and pooled connections need timeouts and lifecycle handling. Measure cold and warm requests separately.

The request path is a chain of independently observable steps; tracing connects client timing to server-side work.

HTTP/1.1, HTTP/2, and HTTP/3 share HTTP semantics but use different message framing and transport paths. Identify whether the problem is connection setup, transport loss, request serialization, or application dependency before changing protocol settings.

Method semantics inform retry safety, but applications must still account for timeouts where the server may have completed work before the client lost the response. Use idempotency keys or resource identifiers when a repeated request could duplicate a charge or job.

Document resource shape, pagination, status codes, error format, authentication, and compatibility expectations. A stable contract makes independent client and server releases possible.

Use cursors for large feeds, offsets where simplicity and predictable small datasets justify them, and explicit versions only when compatibility requires them.

The API format affects observability, generated clients, gateways, caching, and failure handling. Choose the least complex contract that lets the consumers express their needs.

Real-time delivery is not a guarantee of unlimited throughput or durable delivery. Define whether clients may miss events, how they resume (for example, an event cursor), and what happens when a slow client cannot keep up.

Load balancers need redundant deployment, connection draining, timeouts, and observable health checks. Select L4 or L7 based on the routing decision; choose algorithms based on capacity and request variation; avoid affinity unless it solves a real state constraint.