Archive / Topic
#distributed systems
6 posts, newest first
Return the first outcome when an idempotency key repeats
Duplicate suppression is only half the contract; callers also need a stable account of what the original request produced
An idempotency key can expire before its risk does
Retry safety depends on the lifetime of the original side effect, not only the convenience of a short deduplication window
Separate request identity from attempt identity
Retries stay auditable when the customer's command keeps one identity and every execution receives another
Timeout budgets should leave room for the caller
A downstream deadline that consumes the entire request window leaves the upstream service no time to classify, record, or recover from the result
Name the boundary before you promise ordered delivery
An ordering guarantee is useful only when the producer and consumer agree on which messages belong to the same sequence
Reconciliation needs its own idempotency boundary
A recovery action can be safe to retry while still being unsafe to repeat after new evidence arrives
Often tagged alongside distributed systems