Idempotent consumers and the inbox
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
apply each event once in effect, even if delivered many times.
Planned topics
- Brokers redeliver after crashes, rebalances, and timeouts. Duplicates are normal.
- Natural idempotency:
SET status = 'PAID'is safe to repeat;balance = balance - 10is not. - Inbox table: store the processed message id with a unique constraint, in the same transaction as the effect.
- Insert the id first; a duplicate key means "already done", so skip.
- An in-memory set is not enough: it is lost on restart.
Draft outline details
Demonstration
@Transactional
void on(StockReserve msg) {
if (!inbox.tryInsert(msg.eventId())) return; // unique violation: duplicate
stock.reserve(msg.sku(), msg.qty());
}Check your understanding
Why must the inbox insert and the stock change share a transaction?
Show answer
Otherwise a crash between them either skips the work or repeats it.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.