Time Limiting

When an application calls a remote API, a slow or unresponsive dependency is often worse than an outright error. A request that hangs holds onto a connection, a worker and memory for the entire duration, and under load these blocked operations pile up until they exhaust the resources the rest of the system depends on. Time limiting puts an upper bound on how long any single call may take, so a sluggish service degrades into a fast, predictable failure instead of a slow, spreading one.

The pattern is simple: every outbound request is given a deadline. If the remote API has not answered within that budget, the call is abandoned and a timeout error is returned to the caller. The caller can then react immediately, by serving a fallback, failing cleanly, or letting another resilience pattern take over.

Implementation

HARP sits between your application and the remote APIs it calls, so it can enforce a deadline on every request without any change to application code. Its HTTP client accepts a timeout, in seconds, that defaults to 30:

http_client:
  timeout: 10.0

Lowering it makes calls fail faster when an upstream is slow; raising it gives slow but legitimate operations more room to complete.

Time limiting works best alongside the other reliability patterns. A timeout is what the Retry pattern reacts to when it decides to attempt a call again, and repeated timeouts are one of the failures a circuit breaker counts before it trips and starts failing fast. Choosing a deadline is a balance: too generous and slow calls keep consuming resources, too strict and you turn transient slowness into avoidable errors.