YonLinker Idempotency: Safe Retry, Replay and Reconciliation
Design business keys, processing states and replay controls for orders, journals and stock messages so network retries do not duplicate outcomes.
Learning objective
Prove that repeated delivery produces one business result.
Roles
Business owners, data or integration leads, IT operations, security and audit
Prerequisites
- Repeated messages create one result.
- Key conflicts are blocked and alerted.
- Replay retains approval and audit.
Completion checks
- Repeated messages create one result.
- Key conflicts are blocked and alerted.
- Replay retains approval and audit.
Common errors
- Using timestamps as keys.
- Expiring keys too early.
- Blindly rerunning partial batches.
Thailand project note
For Thailand confirm multilingual data, THB/foreign currency, Asia/Bangkok time, segregation and retention; regulated tax, customs, BOI and statutory accounting require qualified Thai review.
Related modules
Steps
- 01
Choose a stable key per message type and include source-system namespace.
- 02
Persist received, validated, processing, success, rejected and quarantined states plus first result.
- 03
Return the prior result for the same key and content; alert on the same key with different content.
- 04
Separate transport retry from authorised business replay with scope and reason.
- 05
Use checkpoints and compensating actions for partial success; never rerun a batch blindly.
- 06
Retain keys beyond the maximum retry window and monitor storage capacity.
- 07
Test duplicate, concurrent, timeout-after-success, out-of-order and quarantine replay; reconcile.
Implementation notes
- Repeated messages create one result.
- Key conflicts are blocked and alerted.