Aglet

How to learn from duplicate processing boundaries and replay

Duplicate-processing learning defines what makes attempts part of one logical operation and where the single-effect promise applies. Record keys, effect boundaries, retry and replay rules, distinct-operation behavior, and the evidence that proved them for future maintainers, reviewers, and incident responders.

Keep the lesson for the next incident

  1. Document identity and effect scope

    Describe the logical operation key, allowed repetition, durable and external effects, deduplication window or ownership, transaction boundary, acknowledgment, and final state. Explain which values may be repeated and which must occur once. Keep examples structural and free of sensitive payloads.

  2. Keep an overlap and replay journey

    Preserve checks for concurrent attempts, timeout retry, event replay, failure before effect, failure after effect, and two distinct operations. Define expected identifiers, counts, audit evidence, and responses. Assign an owner for updating the journey when the effect path changes.

  3. Recheck after identity or transaction changes

    Review the cases after key generation, uniqueness, locking, transactions, queue claims, external calls, client retries, or event replay changes. Compare single-effect and allowed-repeat behavior again. Add a new case when another effect has a different identity scope or durability rule.

What to carry forward

The learning record should retain logical identity, effect scope, retry and replay ownership, concurrency checks, distinct-operation behavior, and recurrence triggers. It is complete when future engineers can state exactly what must happen once and verify it across every repeat path.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow