zlacker

[return to "Idempotency keys for exactly-once processing"]
1. pyroli+7hg[view] [source] 2025-12-05 23:52:37
>>defly+(OP)
This article glosses over the hardest bit and bike sheds too much over keys.

> Critically, these two things must happen atomically, typically by wrapping them in a database transaction. Either the message gets processed and its idempotency key gets persisted. Or, the transaction gets rolled back and no changes are applied at all.

How do you do that when the processing isn’t persisted to the same database? IE. what if the side effect is outside the transaction?

You can’t atomically rollback the transaction and external side effects.

If you could use a distributed database transaction already, then you don’t need idempotent keys at all. The transaction itself is the guarantee

◧◩
2. ivanba+BKg[view] [source] 2025-12-06 04:49:21
>>pyroli+7hg
i get what you are saying, but i don't think it's fair to call it bike shedding, getting the keys right is also important, one can easily screw up that part too
[go to top]