When building event-driven applications it’s good to understand what happens if your event fails to reach consumers, what your broker may do for you or what you need to manage yourself.

Dead-letter queue

• Place where events can go when failed to be delivered to consumer
• Events can fail to be delivered, do you want to store them? (before they are dropped)
• Use queue to debug errors or replay events back into system
• For more information you can read Dead letter channel enterprise integration pattern.

Redrive policies

• Some brokers may redrive (retry) events for you if they fail
• Example of failures may be due to network conditions or permissions
• Example of this would be Amazon EventBridge that retries event delivery for 24 hours with back off.
• Events could be dropped/lost (setup dead-letter queue to capture them)

Archive/Replay

• Store events that were raised and replay them into broker.
• Worth making sure consumers are idempotent as messages may be replayed more than once
• Outbox pattern can be used to store events before sending them.

Dropping events

• Some event brokers may just drop the event if it cannot process it
• Many brokers will retry given conditions, but worth checking and handling failures

Extra Resources

• Dead-letter channels - Interested to know more about dead-letter channels? Worth reading the enterprise integration pattern.
• Understanding Idempotency - Depending on your broker depends if events will get resent to consumers. Understanding idempotency can help.
• Things to consider when building EDA applications - Dead-letter queues / management is just one of them, there are more things to consider when building EDA applications, visual here to help.
• Message Delivery - What delivery method is your broker using? Understanding can help.
• Good and hard parts of EDA - What are the good and hard parts of building EDA applications? Visual for more information.