Make repeated events safe
Course overview · 4 min reading + 12 min practice, estimated
Principles and method
Distributed systems may deliver an event more than once. Idempotency means repeating the same intended operation does not create additional effects. Define a key using the business operation, such as application, interview and version, rather than a random value on every retry. Store operation state durably and consider concurrent attempts. Exactly-once delivery claims need careful scrutiny; practical designs often combine at-least-once delivery with idempotent handling. Do not assume that suppressing duplicate logs prevents duplicate external actions. The external provider’s capabilities and reconciliation route matter.
Worked example
Two workers receive the same booking event. A durable operation record allows one to create the invitation while the other sees it is already in progress or complete. A new interview version uses a distinct operation key.
Put it into practice
Specify an idempotency key and handling for simultaneous duplicate events.
Use fictional information and keep your work in your own notes.
Compare your approach: self-review guidance
Explain how the key stays stable across retries and changes for a genuinely new operation. Include what happens if the worker crashes after the provider acts but before local completion is recorded.
Sources and further reading
Original Academy teaching and fictional examples. These references provide context, not endorsement. Edition 2026.09; updated 2026-09-24.
- GOV.UK: Responsible AI in recruitment
UK guidance on procuring and deploying recruitment AI.
- NIST: AI Risk Management Framework
Voluntary framework for organising AI risks and controls.