wtf( )unctionsystem design, drawn
← all problemsDistributed SystemsMedium

The same message, twice

A payments consumer reads from an at-least-once queue. During a rebalance the same event is redelivered — the customer is emailed twice and the ledger credited twice.

Redelivery isn't a bug you can configure away. Every queue worth using delivers at least once, because the alternative is delivering at most once and losing messages.

Make a second delivery do nothing.
Components — tap one, then tap a slot on the diagram
!The same payment event arrived twice. The customer was emailed twice and credited twice.

Boundaries, outermost first: One transaction: Ledger (the side effect; FAILED: credited twice), an empty slot for the what makes a repeat harmless Outside every boundary: Consumer, Queue (at least once) Connections: Queue publishes to Consumer — may repeat (step 1) Consumer calls what makes a repeat harmless (step 2) what makes a repeat harmless calls Ledger — once (step 3)

Ledgerthe side effectcredited twice
Consumer
Queueat least once