A microservice-based application experiences transient faults due to network instability.

Transient faults, brief, temporary failures caused by momentary network instability, packet loss, or short-lived service unavailability, are, by definition, likely to resolve themselves quickly if the failed operation is simply attempted again after a short delay. Retry logic with exponential backoff automatically re-attempts the failed call, progressively increasing the wait time between successive retries, which both gives the transient condition time to clear and avoids overwhelming an already-struggling downstream service with an immediate flood of repeated requests. This pattern is the widely recognized best practice specifically designed for handling transient faults in distributed and microservice-based architectures. Switching network providers (A) is a drastic, impractical, and slow response to brief, transient instability, and does not represent an application-level resiliency pattern at all. Logging faults and alerting support (C) provides visibility and after-the-fact awareness, which is useful for tracking patterns over time, but does not itself resolve the immediate failed operation or allow the application to continue functioning through the transient condition. Increasing the timeout period (D) may allow a single slow operation more time to complete, but it does not address outright failures and can make the application feel unresponsive by making callers wait longer without addressing the root behavior of retrying intelligently. Retry with exponential backoff is correct.

Reference topic: Fault Tolerance Techniques - Handling Transient Faults in Distributed Applications.