A client calls an unreliable downstream API. What should it implement?
Why D is the answer
Retries with exponential backoff
Backoff gives a service room to recover. Tight loops make an outage worse.
In detail
- Backoff gives the service time to recover.
- Add jitter, and cap the attempts.
Use case
An illustrative scenario, not a real incident.
A partner API fails now and then. Retries with exponential backoff wait longer each time, so the service can recover.
See it in different ways
mindmap
root((Messaging))
Event Grid
Events
Filters
Service Bus queue
One worker per message
Service Bus topic
Many subscribers
Own filters
Dead-letter queue
Failed messagesflowchart LR S0["Call fails"] --> S1["Wait"] --> S2["Retry"] --> S3["Wait longer"] --> S4["Give up at the cap"]
Key point: Back off between retries.
Why the other options are wrong
- A. An infinite loop with no delay
- A tight loop adds load.
- B. A larger request body on each attempt
- A larger body does not help.
- C. A new API key for each failed call
- A new key does not fix an unreliable service.