zlacker

[return to "Idempotency keys for exactly-once processing"]
1. manoDe+mYf[view] [source] 2025-12-05 21:46:00
>>defly+(OP)
> The more messages you need to process overall, the more attractive a solution centered around monotonically increasing sequences becomes, as it allows for space-efficient duplicate detection and exclusion, no matter how many messages you have.

It should be the opposite: with more messages you want to scale with independent consumers, and a monotonic counter is a disaster for that.

You also don’t need to worry about dropping old messages if you implement your processing to respect the commutative property.

◧◩
2. itisha+X3g[view] [source] 2025-12-05 22:22:45
>>manoDe+mYf
> It should be the opposite: with more messages you want to scale with independent consumers, and a monotonic counter is a disaster for that.

Is there any method for uniqueness testing that works after fan-out?

> You also don’t need to worry about dropping old messages if you implement your processing to respect the commutative property.

Commutative property protects if messages are received out of order. Duplicates require idempotency.

◧◩◪
3. hobs+Ijg[view] [source] 2025-12-06 00:15:10
>>itisha+X3g
hash your thing you want to do and see if you did it recently or in order by hashing each thing you wanted to do in order to get a new hash of all the things you did in the order you did it in one value.
[go to top]