Learn the vocabulary of recording incoming messages so a redelivery is recognized and skipped instead of reprocessed.
0 / 5 completed
1 / 5
At standup, a dev mentions writing every incoming message to a durable inbox table with a deduplication key, in the same transaction as marking it received, so that if the same message is redelivered later, the consumer recognizes it and skips reprocessing it instead of applying its effects twice. What is this messaging pattern called?
The transactional inbox pattern is exactly this: it writes every incoming message to a durable inbox table with a deduplication key, in the same transaction as marking it received, so that if the same message is redelivered later, perhaps because an at-least-once messaging system retried it, the consumer recognizes the duplicate via its dedup key and skips reprocessing it instead of applying its effects twice. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This record-and-recognize-redeliveries approach is exactly why the inbox pattern lets a consumer safely handle a messaging system that might deliver the same message more than once.
2 / 5
During a design review, the team adds a transactional inbox table to an order-processing consumer, specifically because recording each message's dedup key in the same transaction as processing it means a redelivered message is recognized and skipped instead of being processed a second time. Which capability does this provide?
A transactional inbox table here provides safe handling of redelivered messages, since the inbox table lets the consumer recognize a message it has already processed and skip it, instead of applying that message's effects, like charging a customer, a second time. Processing every incoming message with no record of what's already been handled means a redelivered message, which an at-least-once messaging system can and does send, gets applied twice. This recognize-and-skip-duplicates behavior is exactly why the transactional inbox pattern is the standard fix for consumers on at-least-once delivery systems.
3 / 5
In a code review, a dev notices an order-processing consumer applies every incoming message's effects immediately with no record of which message IDs have already been processed, meaning a message redelivered by the messaging system would be processed and charged again. What does this represent?
This is a missed opportunity to apply the transactional inbox pattern, since recording each processed message's dedup key would let a redelivered message be recognized and skipped instead of being charged again. A cache eviction policy is an unrelated concept about discarded cache entries. This no-record-of-processed-messages pattern is exactly the kind of double-processing risk a reviewer flags once the messaging system is confirmed to redeliver messages under an at-least-once guarantee.
4 / 5
An incident report shows a customer was charged twice for the same order, because a messaging system redelivered a message after a network blip, and the order-processing consumer had no record of which message IDs it had already processed, so it applied the charge again. What practice would prevent this?
Adding a transactional inbox table that records each message's dedup key in the same transaction as processing it lets a redelivered message be recognized and skipped instead of being charged again. Continuing to process every incoming message immediately with no record of already-processed message IDs regardless of how often a redelivered message gets applied twice is exactly what caused the double charge described in this incident. This add-a-transactional-inbox approach is the standard fix once a consumer is confirmed to be receiving redelivered messages from an at-least-once messaging system.
5 / 5
During a PR review, a teammate asks why the team adds a transactional inbox table instead of simply asking the messaging system's operator to configure exactly-once delivery so redeliveries never happen in the first place. What is the reasoning?
A transactional inbox table makes the consumer's own processing idempotent regardless of what the underlying messaging system actually guarantees, while true exactly-once delivery across a distributed messaging system is extremely difficult to guarantee end to end, and many widely used messaging systems only ever offer at-least-once delivery, still requiring the consumer to handle a redelivery safely. This is exactly why the transactional inbox pattern is the standard, robust fix, rather than depending entirely on the messaging system to prevent redeliveries.