When we build event-driven architectures we use events to communicate between services and domains, these events are often used to trigger async processes downstream, and we can use event-driven architectures to create decoupled and scalable solutions.

It’s also important to know that the events we use to communicate can also be valuable for businesses and create new opportunities (e.g. Using events to process data in real-time).

Competitive advantage

Many companies rely on batching to process data and generate reports after events occur, event-driven architectures can give organisations options to process information when events occur. For example, companies are using event streaming to process events in real-time for downstream consumers (e.g. Reporting). If we move data processing closer to the time it occurs, we can get more value from it.

Publishing business events

There are many types of events when building event-driven architectures, and business events are part of that. We use events to communicate between systems, but we can also use events to notify parties of critical business metrics we can use to make decisions.

New Consumers = New Value

Producers are decoupled from consumers, when new business opportunities arise we can add consumers onto events already there. Today you may not see business value in certain events, in the future the value may unlock, having this producer/consumer relationship can help.

Tables store state, events tell the story

Many applications query some database for the state of a given entity, for example a query to find the location of a package right now for a given user. This is great, but how we can determine where the parcel has been? We can use events to tell the story. Keeping an event log can help us understand how things ended up the way they are.

Extra Resources

• Designing data-intensive applications - Book has some great chapters on event streaming.
• Types of events - There are many types of events, understanding them can help.
• Learning Domain Driven Design - Some notes taken from the book “Learning Domain Driven Design” by Vladik Khononov.