When building distributed message/event-based architectures it’s important to consider and think about idempotency.

Messages/events can be replayed to your consumers, this means you need to handle the same message being played more than once. This might happen if you have failures, network issues or maybe you need to replay a bunch of events, either way thinking about idempotency up front can help.

Implementing idempotent consumers can be easier in some consumers than others depending on the logic inside your applications, but when you design or write your applications just think “What happens if this SAME event was to trigger again”, what side effects will you have? Things will fail, helps being prepared for that.

Idempotency keys

Some patterns to solve this issue to store the fact that the event has been processed before using idempotency keys, this is where you hash the events or part of the event, and use persistence storage to store the fact the events has been processed (maybe with the result of the initial process). There are tools and libraries out there to help you with this, but it’s worth exploring.

Extra Resources

• Message Delivery - Will your events naturally get replayed for you? Could depend on your broker of choice and how you handle messages/events, worth understanding at-most-once, at-least-once and exactly-once delivery.
• Good and hart parts of EDA - Understanding idempotency can take awhile to wrap your head around if you are new to it, but there are also some things to consider when building EDA applications (Error Handling, Debugging).
• Idempotent Receiver - Summary from the book enterprise integration patterns.
• Open Source project Powertools Idempotency helpers - Using AWS Lambda? Powertools is a great open source project with many different utilities to help you build performant Lambda functions. The project also can utils to help you deal with idempotency, worth checking out.