A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. A technical eventId identifies one delivery, while a business key identifies the same effect expressed by different events. Robust dedupe needs both.
Distributed correctness comes from idempotency keys, leases, monotonic versions, and reconcilable facts—not an assumption of one delivery. A timeout means unknown outcome, not confirmed failure.
Questions the design must answer
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Insert a unique eventId inside the consumer transaction before state mutation; protect irreversible effects with a businessKey and retain deletion tombstones.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Treat cleanup as protocol behavior: timers, handles, queues, and temporary data must be safely releasable in every terminal state.
The delivery standard for Deduplication Under At-Least-Once Delivery: Windows and Tombstones is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.
- A TTL shorter than maximum message delay reactivates old duplicates, while Redis-only dedupe forgets history after eviction, failover, or cold start.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
Prove that it works with evidence
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Send the same eventId, a new eventId with the same business key, and a very late pre-delete event; verify outcome, audit, and retention policy.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.