Skip to main content

Delivery duplicates and inbox effects

What this concept is​

An inbox associates a stable event identity with a completed local effect. Recording that identity and changing the business state in the same transaction lets duplicate deliveries become harmless for that local effect.

Why it matters here​

A relay can publish successfully and fail before recording sent. Retrying must publish again rather than risk losing the event. Thus one business event may be delivered multiple times even when producer state was committed only once.

Concrete example​

Relay appends a to the broker, then fails at after_publish. The outbox still says unsent. Retry appends a again and marks it sent. Consumer first delivery inserts inbox a and adds 7. The second finds the same payload already recorded and leaves the balance at 7. Two deliveries, one local effect.

Common confusion / misconception​

Recording an inbox marker before a separately committed effect can lose the effect: retry sees the marker and skips work. Applying the effect before separately recording the marker can duplicate it. Both must share one local transaction. Checking a Python set is not durable deduplication.

How to use it​

Use the unique inbox key as part of the database transaction and validate repeated payloads. Inject failure after the marker, after the effect and after commit. The first two leave neither marker nor effect; after commit preserves both. Acknowledge processing only after successful commit in a real adapter. The supplied broker list has no acknowledgment API or real consumer group.

Check yourself​

Why is marking sent before publishing unsafe? Why does a unique inbox ID without atomic effect updates fail to establish the intended guarantee?

Mini drill or application​

Deliver a:7, b:7, a:7 and c:0 in two orders. Predict balance 14 and three inbox entries. Explain why equal amounts are different events and why zero amount still gets an inbox marker.

Read this only if stuck​

Use DDIA on idempotency and SQLite transactions for the local transaction behavior. Keep the argument tied to the two tables and the declared failure model.