When building event-driven architectures you will use message/events to pass information between systems. What goes into these messages is up to you. This is great as it becomes flexible, but also a problem because it’s flexible!

Many people building event-driven solutions start by raising messages/events between systems, without much thought about event design. What goes into your events, what should you include in your events?

Years later, many folk’s structure to version, document and consumers can find it hard to understand the payload of these events due to lack of design.

Prevent confusion between producers and consumers

• Event-driven architectures are becoming more accessible to us (talk about this in my talk), with more producers and consumers getting integrated into systems.

• Poor event design can lead to integration confusion between producers and consumers.

• Events need clear naming intent and it can help to have standards within each of your events.

• Standards make it easier to version your events, validate them and write tools supporting your events.

• You can specify your own standards internally or lean into CloudEvents to help you define your standards.

• Think about your event design when building event-driven architectures, think about how others will consume these events.

• Don’t expose implementation details in your events.

Event first thinking

• When designing APIS we tend to write documentation, specifications, versioning strategies and much more. When designing events, the same cannot be said.

• When designing your events, take what we have learnt from API management and apply these principles to your event design.

• Consider how are you going to version your events, who is the targeted audience of your events? Are you going to document your events?

• Use domain experts within your organisation to help you design your events, if they are integration events.

• Consider what types of event you are designing, is it private or an integration event. Both mean different things, your design will impact this.

• Don’t let events be an afterthought. Consider some design up front and evolution strategies for them. Think event first.

Bad design slows down integrations

• Bad event design can slow down integration between producers and consumers.

• Event-driven architecture thrive on consumers coming and going, and designing decoupled architectures. Bad event design can slow this process down and cause frustrations.

• Be clear on the naming and event payloads of your events, think about the fields you want to expose and the naming/intent of them.

• Don’t let consumers guess what your fields mean, be clear in their intent.

• Make sure you understand and can unlock value in your events.

• Think about standards, what standards do you want to include in your events? What are your naming conventions? What headers do you want in include?

Extra Resources

• Awesome event patterns - Open source collection of event patterns I have made. Here you can explore more details about the types of event patterns you may come across.

• EventCatalog - Open source tool I created to help developers and teams document their events.

• Event Design and Event-first thinking - A talk I gave at GOTO talking about event design and it’s important. I dive deeper into types of events and why you may want to use or not use them.

• Journey to event-driven architecture - A talk I gave at re:Invent 2023. I talk about the journey of building event-driven architectures and common pitfalls people may have and how to avoid them.

• CloudEvents - A specification for describing event data in a common way. Worth reading and learning.

• Event-driven architecture with domain driven design - I visual I created to help you understand why EDA and DDD work so well together. When designing events it’s important to consider your domains!

• What is Event Storming? - Another visual to help you understand Event Storming with extra resources. A great tool to help you identify events within your systems.

• Internal vs External events - Visual here to help you understand internal and external events.