When the System Retries Failed Requests

Your system needs clear rules to determine when a failed request should be retried. Not every error is suitable for a retry; some failures require different handling. Understanding the criteria and conditions for retries helps you build a robust, reliable application.

Criteria for Retrying Requests

• The error is transient: errors like network timeouts, temporary service unavailability, or rate limits often resolve on their own;
• The request is idempotent: repeating the request does not cause unintended side effects, such as duplicate transactions;
• The failure is not caused by invalid input: do not retry if the request fails due to incorrect data or authentication errors;
• The maximum number of retries has not been reached: avoid endless retry loops by setting a retry limit.

Common Retry Conditions

• Network timeouts: if the request does not receive a response within the expected time;
• HTTP 5xx errors: server-side errors like 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout;
• Connection errors: failures to establish a network connection or dropped connections during communication.

When Not to Retry

• HTTP 4xx errors (except 429 Too Many Requests): these usually indicate client-side problems like bad input or unauthorized access;
• Non-idempotent operations: retrying actions that change state (such as creating new records) can cause data inconsistencies.

By defining clear retry criteria, you ensure your application responds to failures intelligently, improving reliability without risking data integrity or unnecessary load on external services.

Applying and Monitoring Timeouts

Timeouts are essential for preventing requests from hanging indefinitely and blocking system resources. When you set a timeout, you define a maximum period that a request can take before the system automatically cancels it.

How Timeouts Work Internally

• When you initiate a request, the system starts a timer in the background;
• If the request completes before the timer expires, the system processes the response as usual;
• If the timer reaches the timeout value before a response is received, the system cancels the request and triggers an error event.

Monitoring Timeouts

• The system logs every timeout event for monitoring and troubleshooting;
• Metrics on timeout frequency and affected endpoints are collected and made available through dashboards;
• Alerts can be configured to notify you if timeouts exceed a defined threshold, helping you quickly identify performance issues.

Example: Configuring a Timeout

You can configure a timeout for an HTTP call like this:

RestTemplate restTemplate = new RestTemplateBuilder()
    .setConnectTimeout(Duration.ofSeconds(5))
    .setReadTimeout(Duration.ofSeconds(10))
    .build();

Here, the connection timeout is set to 5 seconds and the read timeout to 10 seconds. If either limit is reached, the request is automatically terminated.

Benefits of Timeouts

• Prevent resource exhaustion caused by stuck or slow requests;
• Improve overall system reliability and responsiveness;
• Enable better error handling by allowing you to respond to failures quickly.

By applying and monitoring timeouts, you ensure that your system remains stable and responsive, even when external dependencies are unreliable.

Simple Analogy: Mailing a Letter

Imagine you are sending an important letter by mail:

• Retry: If the mail gets lost or delayed, you send the letter again after waiting a short period;
• Timeout: If you do not receive a response within two weeks, you stop waiting and take another action.

This mirrors how retry and timeout work in software:

• Retry: Attempt an operation again if it fails;
• Timeout: Give up if the operation takes too long.

These strategies help ensure your application stays reliable, even when things go wrong.