December 5, 2025
Exactly-once? Comment wars!
Idempotency Keys for Exactly-Once Processing
Can apps do things just once? Commenters spark a counter war
TLDR: Engineers propose unique keys and one-shot database commits to prevent repeat processing. Commenters clash: some want simple counters like TCP, others warn monotonic numbers hurt scaling and prefer time-limited keys for APIs; it matters for payments and anything that must never double-charge.
The article pitches a simple dream: you can’t guarantee delivery, but you can make apps process exactly once by tagging each message with a unique “do-not-repeat” key and saving both the result and the key together—do it all at once or not at all. That’s the plan. The crowd? Instantly split. One camp waves the “use counters like TCP” banner, arguing you can number messages and spot duplicates. Another camp fires back: random IDs (aka UUIDs) mean you might have to remember every key forever—yikes—so people suggest time-stamped IDs like UUIDv7/ULID to safely reject “too old” messages. Then comes the real brawl: monotonic sequences (ever-increasing numbers) make life easy for the receiver, but manoDev calls them a scaling nightmare when you want many independent workers. Meanwhile, eximius says the whole thing mainly helps streaming; for web APIs, just let users send a custom key and store it briefly with a TTL (time limit). The comments go full sitcom: hinkley claims resilient systems secretly become mini project managers with milestones, and bokohut flexes a late-’90s battle story about a custom UID hero saving a payment firehose. It’s Team Counter vs Team Chaos vs Team “Did this in ’99,” and we are here for it.
Key Points
- •Exactly-once delivery is not guaranteed in distributed systems, but exactly-once processing is achievable using idempotency keys.
- •Processing and persisting the idempotency key must be atomic, typically via a database transaction, to ensure reliable duplicate handling.
- •UUIDv4 provides unique keys but requires storing all past keys; discarding keys risks undetected duplicates.
- •Time-ordered identifiers (UUIDv7, ULID) let consumers flag messages with old keys and coordinate with producers (e.g., in payment flows).
- •Monotonically increasing sequences allow consumers to store only the latest key (per partition/producer), simplifying detection but complicating producer key generation.