Idempotency and retries
Retrying a request without paying twice: idempotency, idempotency keys, exponential backoff with jitter, and what “at least once” delivery implies. Scenarios and failures, every answer explained.
- 33 cards
- 3 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Idempotency
- Retrying
- Delivery guarantees
A few cards from the deck
What is “idempotent operation”?
Show the answer
An operation that produces the same result whether it runs once or several times
It can be replayed safely after an error: that is what makes retries safe.
Which of these operations is idempotent?
- Set an order's status to “shipped”
- Add €10 to a balance
- Create a new order
- Send a welcome email
Show the answer
Set an order's status to “shipped”
Setting a value twice leaves the same state. Adding, creating or sending twice produces a duplicate effect.
An operation that produces the same result whether it runs once or several times: what is this called?
Show the answer
idempotent operation
It can be replayed safely after an error: that is what makes retries safe.
According to HTTP semantics, which method is not idempotent?
- POST
- PUT
- DELETE
- GET
Show the answer
POST
PUT replaces a resource with a given value, DELETE removes it, GET reads it: repeating them changes nothing more. POST creates or triggers, and may act on every call.