Idempotency Keys
Make retried commands return one durable outcome.
Problem
Networks lose responses, so a caller cannot know whether a mutation happened.
When to use it
- Creating payments, orders, bookings, or jobs
- A client or broker will retry
When not to use it
- Pure reads
- The operation is naturally idempotent and cheap
Minimal example
Store (actor_id, key, request_hash, status, response). Reject a reused key with a different hash; replay the stored response.
Tradeoffs
- Needs retention and concurrent in-progress behavior
- Scope keys to an authenticated actor