HTTP Client Configuration

HTTP clients need appropriate connection, read, response, and connection-pool settings for reliable service-to-service calls. Good configuration prevents requests from hanging indefinitely while balancing latency, resource usage, and resilience.

An HTTP client manages the network connection between one service and another. Important settings include the connection timeout, which limits how long the client waits to establish a connection, and the request or response timeout, which limits how long an operation may take after the request starts.

Connection pooling lets a client reuse established TCP connections instead of creating a new connection for every request. Pool size should match expected concurrency and the capacity of the downstream service; too few connections can create client-side queuing, while too many can increase resource consumption and overload the server.

In Java's standard `java.net.http.HttpClient`, `connectTimeout` controls connection establishment and `HttpRequest.timeout` limits the request operation. More advanced clients such as Apache HttpClient or OkHttp provide additional controls for connection pools, connection leasing, socket/read behavior, and other transport details.

Timeouts should be finite and chosen according to the service's expected latency and caller requirements. A timeout is not a retry policy: retries must be designed separately and should account for idempotency, backoff, and the risk of multiplying load during an outage.

Key points

Interview questions

Why should an HTTP client have a connection timeout?

A connection timeout prevents the caller from waiting indefinitely while trying to establish a network connection. Without a bound, blocked requests can consume threads or other resources for too long. The value should reflect the application's latency requirements and network environment.

What is the purpose of connection pooling?

Connection pooling allows an HTTP client to reuse established connections for multiple requests. This avoids repeatedly paying connection-establishment costs and can reduce latency. The pool still needs sensible limits because every active connection consumes resources and creates load on the downstream service.

How would you choose HTTP client timeout values?

Start with the caller's latency budget and the expected latency of the downstream service. The connection timeout should be short enough to detect unreachable endpoints without creating unnecessary delays, while the request timeout should leave enough time for legitimate responses. Production values should be validated with latency measurements and adjusted as service behavior changes.

What is the relationship between HTTP client timeouts and retries?

They solve different problems. A timeout limits the duration of an individual attempt, while retries determine whether another attempt occurs after failure. Combining retries with long timeouts can make the total operation much slower, so the overall retry budget must fit within the caller's deadline. Retries should also consider whether the operation is safe to repeat.