Things to consider when building EDA architectures By David Boyne

Things to consider when building EDA architectures By David Boyne

Things to consider when building EDA architectures

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

Want to work together?

If you're interested in collaborating, I offer consulting, training, and workshops. I can support you throughout your event-driven architecture journey, from design to implementation. Feel free to reach out to discuss how we can work together, or explore my services on EventCatalog.

Download EDA Visuals

Join over 13,000 others learning EDA and download all the EDA visuals directly to your computer. This document updates everytime a new visual is added so make sure you come back to get the latest.

Download now →
Diagrams and thoughts by @boyney123 to help you learn.