Make repeated event delivery safe without accidentally discarding legitimate updates.
Expect repeated delivery
A provider may retry when it cannot confirm receipt. Your application can also time out after completing work. Design the handler so repeating the same event does not duplicate the business action. This is especially important for payments, stock changes and messages, where duplicate work has a visible consequence.
Choose a stable identity
Use the provider’s event identifier where appropriate and understand its scope. Store processing state with the operation it protects. A naive check followed by a separate write can still race under concurrent requests. The right persistence approach depends on the system, but the business requirement is one consistent outcome for the same event.
Verify before processing
Validate authenticity using the provider’s documented mechanism and avoid trusting arbitrary incoming payloads. Record relevant metadata without retaining secrets. Reject malformed requests and handle unknown event types deliberately. A public endpoint should not treat every correctly shaped request as an authorised instruction.

Handle order and recovery
Events may arrive late or out of sequence. Compare the current record state before applying a change. Give failed handlers a retry process and monitor work that remains unresolved. Test concurrent duplicate events, not only a repeated request sent after the first one has already finished.
Your next working session.
- Identify repeated events
- Verify the sender
- Test concurrent delivery
Bring one real, anonymised example to the discussion. Work through the choices above with the person responsible for the outcome, record the unresolved questions and agree who will investigate them.
Elite Apps editorial · Practical planning guidance. Examples and diagrams are illustrative; implementation depends on your requirements. Technical and supplier guidance can change.