Idempotency Is Easy Until the Second Request Is Different
14 points by typesanitizer
14 points by typesanitizer
Article focuses a little too much on the perspective of the server, but doesn't really dive into the needs of the client. For a lot of the cases presented, I think what a client expects is really pretty straightforward?
Many production queue integrations are effectively at-least-once from the consumer’s point of view. Even when the broker advertises stronger delivery semantics, your business side effects still need deduplication. Exactly-once delivery is not exactly-once business effect.
I shake just a little when I see "exactly-once delivery". We should be telling clients it's at-least-once or at-most-once -- and then giving them the tools to behave accordingly (including idempotency as one).
Definitely a neat article on the perils of idempotency, but it reads to me as LLM-written somehow
Yeah, "That is not idempotency. That is reinterpretation." as a standalone paragraph sounds very GPT-family to me, but I suspect it was human written and LLM-edited.
To comment on the content: The hashing advice to normalize into a DTO first makes sense, the naive hashing implementation I was thinking about before the article got to it could have missed some edge cases.
On the idempotency key header: I don't think the article mentions or links out to it, but it's actually standardized: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Idempotency-Key