When a call fails: timeouts, retries and doing it once
Published Updated
This is the Learning Atlas from Orbit. Get your invite
Concepts and methodology
-
Step 1: Timeout
Why this matters here
First bound how long checkout waits while remembering that a timed-out payment may still finish.
In short
A limit on how long your program waits for an operation before it stops waiting and reports a failure.
-
Step 2: Retry
Why this matters here
Then distinguish temporary failures worth another attempt from errors needing correction.
In short
Another attempt at an operation after an earlier attempt failed or its outcome could not be confirmed.
-
Step 3: Exponential backoff
Why this matters here
Space repeated attempts farther apart so a struggling service has time to recover.
In short
A retry schedule that increases the waiting time by multiplying it after successive failures.
-
Step 4: Circuit breaker
Why this matters here
Pause calls to a repeatedly failing dependency before its delays spread through the app.
In short
A rule that temporarily stops calls to a repeatedly failing service, then allows a limited test of whether it has recovered.
-
Step 5: Idempotency
Why this matters here
Make repeated payment requests produce one result with no double charge before enabling retries.
In short
The property that repeating the same intended operation has the same effect as doing it once.
-
Step 6: Webhook
Why this matters here
Close with payment notifications, where duplicate delivery makes the same protections necessary.
In short
An HTTP request one system sends to your app when an event happens, such as a payment succeeding.