Transactions and Idempotency
Protect data consistency when requests retry, fail halfway, or run concurrently.
Recommended approach
- Use DB transactions for multi-step writes that must succeed or fail together.
- Add idempotency keys for externally retried operations (payments, webhooks, order creation).
- Persist operation status for safe retries.
Alternatives and when to choose them
- Outbox pattern when async event publication must stay consistent with DB writes.
- Saga/process manager for long-running cross-service workflows.
Implementation checklist
- Identify non-idempotent endpoints and protect them.
- Add uniqueness constraints that reinforce idempotent behavior.
- Define retry semantics per operation.
Common pitfalls
- Idempotency implemented in memory instead of persistent storage.
- Long transaction scopes including network calls.