When you start building event-driven applications you start to write producers and consumers and you start to see value quite fast. Over time as more producers and consumers are added you will start to face some common issues (these issues listed are all problems I have experienced and seen in the community)

Lack of idempotency handling

Consumers may process your events more than once (e.g. if events need to replay, or failures etc), your consumers need to handle this. You need to make sure your consumers produce the same outcome regardless of how many times it was called with the same event, having side effects in your consumers (different results) can lead to issues.

Mistaking commands for events

An easy one when you get started, mistaking commands vs events. Here is a visual to help you understand the difference.

Multi purpose events

When you start designing and implementing your events, it’s easy just to add on that one extra field… “what if we add a type field here”, this works and might provide value, but over time your consumers might have a hard time understanding the intent of the event. Rather than having one event to rule them all, why not split them out? Something to think about…

Lack of documentation

Let’s face it, many people don’t like to write documentation, especially as you start to build your EDA applications. Overtime as you add producers and consumers it can be hard to keep track of who is producing what, and who is consuming what. Adding documentation can help. Here is visual with resources to help you.

Leaking implementation details

When you have clear boundaries of services, it can be easy to leak implementation details of your service in your event. Make your events explicit, don’t get consumers to guess what is happening, don’t confuse them with implementation details.

Lack of standards/structure

Overtime you might have 10s or 100s of events in your architecture, think about what goes into these events, maybe you might use CloudEvents or define your own standards, spend time here and think about it.

Extra resources

• Document your event-driven architectures - Visual here to help you understand ways to document your event-driven architectures.
• Identify domains and events with EventStorming - Think about how you are going to identify events in your system. EventStorming can help.
• Message delivery - How are your messages/events getting to your downstream consumers? Understanding this can help.
• Events are important - Event First Thinking - Treat events as a first class citizen in your architecture, doing this from the start can help you.
• Know the difference of types of events you raise - Notification events, Delta events, Event carried state transfer… what does it mean? Important to know.
• Commands vs Events - Quickly learn the difference between commands and events, 5min here can save pain later on.
• Passing events through context - Find your business domains and use events to communicate, you might need to transform them before consumers can understand them… that’s OK, look at these patterns.