I’ve written previously about implementing idempotency keys, an idea stemming from APIs like Stripe’s, but which has gotten wider adoption

Idempotency: The `is_transient` property

submited by
Style Pass
2024-10-31 03:00:02

I’ve written previously about implementing idempotency keys, an idea stemming from APIs like Stripe’s, but which has gotten wider adoption more recently including it’s own IETF draft.

One of the quirks of idempotency keys is that while the responses of successful requests are always captured, errors are more nuanced. They fall into two categories:

Errors that result from properties intrinsic to the request itself. For example, if a caller requests a resource be created with an invalid name, then barring a supremely rare change in naming policy, any number of retries will always result in the same failed response.

Errors that result from some transitory aspect of the system’s state at that time. For example, if a request conflicted with another in-flight request that was modifying the same data.

An idempotency layer can safely cache errors of the former type, but not the latter, which generally includes a set of status codes that are known to be transitory like 409 (conflict), 429 (too many requests – usually rate limiting), and 500 (internal server error). This is how Stripe’s implementation works for example.

Leave a Comment