Anastasiia Ivanova

Good catch, check-then-create never gave you exclusivity, two requests can both read "nothing here yet" a few microseconds apart. Making the claim itself atomic fixes it: insert the key under a unique constraint, so the second writer hits a conflict instead of a false green light, and gets "in progress" back instead of falling through to a second create. Crash after the external effect is the part that key claim can't fix on its own, though. You still need something that checks actual state with the downstream system before deciding what "in progress" turned into. On the retention window, no, I wouldn't read an expired key as proof nothing happened. It just means the provider stopped promising to dedupe. I keep my own case record with its own retention, separate from whatever TTL the provider uses. If the key's gone and a retry shows up, that internal record is what I trust, not the provider's memory.