2 min read
De-duplicate on event ID
Record every event ID you have processed. On receipt, check the store first: if you have seen the ID, acknowledge with a 2xx and stop — the work is already done. This turns at-least-once delivery into effectively exactly-once processing on your side.
Order by state, not arrival
Retries and parallel delivery mean a 'settled' event can arrive before a 'created' one. Do not assume arrival order. Key your state machine on the event's own type and timestamp, and ignore a transition that would move a resource backwards. Verify the signature first — see verifying a signature.
Acknowledge fast, process async
Return a 2xx as soon as the event is verified and enqueued; do the heavy work in a background job. A slow synchronous handler risks a timeout, which Credicorp reads as a failed delivery and retries — creating more duplicates. Fast ack plus idempotent processing is the stable pattern.
Frequently asked questions
How do I make processing exactly-once?
You cannot control delivery, but you can control processing: store each processed event ID and no-op on repeats. That converts at-least-once delivery into exactly-once effect on your side.
What if events arrive out of order?
Treat the event's own type and timestamp as truth, not arrival order. Reject transitions that would move a resource backwards. Never assume a 'created' arrives before a 'completed'.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.
