Help Center/ Well-Architected Framework/ Well-Architected Framework and Practices/ Resilience Pillar/ Rapid Fault Recovery/ RES09 Retries After Failures/ RES09-02 Determining Whether to Retry from the Client Based on the Comprehensive Evaluation Results
Updated on 2025-05-22 GMT+08:00

RES09-02 Determining Whether to Retry from the Client Based on the Comprehensive Evaluation Results

When the requests from a client time out or the client receives error responses, the client needs to determine whether to retry the requests. Retries help the client obtain desired results when requests fail but consume more of a server's time to get successful responses.

  • Risk level

    High

  • Key strategies
    • Retry requests if they time out when messages are lost due to intermittent disconnections or other temporary faults.
    • Retry requests based on error codes. For temporary faults, for example, if an error code indicates that the system is busy, wait for a period of time and then retry the request. For non-temporary faults, you do not need to retry requests.
    • If requests are made through the SDK with the built-in message retry function, the client does not need to retry the requests.
    • In a multi-layer service stack, ensure only the original requester retries the requests to avoid layer-by-layer retry.