APIs and Integration
Prepare timeouts and retries for third-party dependencies
A timeout limits waiting, not necessarily remote execution. Build retry rules around total deadlines, business idempotency, dependency capacity, and a recovery path for outcomes that remain uncertain.
An external service slows down and your application waits. Adding retries can look like a quick reliability improvement, but repeated attempts may increase load or duplicate business effects. Decide how long the customer can wait and what the system should do when that budget expires.
Separate waiting from business outcome
A client timeout tells your application that its wait ended. It does not prove that the remote operation stopped or never started. Recommend explicit states for not attempted, confirmed success, confirmed failure, and unknown outcome. Support teams need these distinctions to avoid restarting completed work.
HTTP advises against automatic retries of non-idempotent methods unless the client knows the request semantics are idempotent or can detect nonapplication.[2] Apply that rule to the actual operation. A vendor’s idempotency mechanism may help, but its scope, retention, and failure behavior still need review.
Allocate a total deadline
Set a budget for the complete customer operation, then allocate connection, response, and processing time within it. Do not select each timeout independently. Leave time to return an understandable result or persist work for later processing.
Recommend one layer that owns retries. If the application, client library, and worker each retry independently, attempts can multiply. Inspect defaults before adding another policy. Use bounded attempts and increasing delays with random variation where suitable. The delay must fit the remaining budget, and the system should stop when another attempt cannot meaningfully finish in time.
Set separate policies for interactive requests and background recovery. A customer screen may stop waiting while an owned recovery task continues, but the displayed status must reflect that distinction.
Classify before another attempt
Separate invalid input and permission failures from transient dependency failures. Even a transient response does not settle whether a write is safe to repeat. Honor provider instructions. Retry-After can express an HTTP date or a delay in seconds, so a generic client must not assume only one format.[2]
- Record one total deadline and the component timeout values.
- Identify the single retry owner and disable conflicting defaults.
- Test slow responses, connection failures, and lost responses after execution.
- Define status lookup or reconciliation for unknown write outcomes.
Hypothetical example: a carrier label request
Hypothetical example: a shipping application requests a label from a carrier. The carrier accepts the shipment, but the response is lost. The application retains the shipment reference and marks the label request uncertain rather than creating another shipment.
A recovery worker queries the carrier before deciding whether another request is appropriate. This can delay the label and requires a visible exception queue when the carrier offers no lookup. Faster failure is not always better customer service. The next action is a failure test that proves what the user sees and what operations staff can recover after the response disappears.
