The Event-Driven Architecture Manifesto

The way that Event-Driven Architectures (EDA) are implemented varies between organisations due to their unique strategies, priorities, and culture. To ensure alignment between business and IT, organisations can use a manifesto: a written statement declaring the motives and views related to a specific subject, in this case EDA. A manifesto can help businesses with a list of guiding principles, and grow with the organisation as their EDA maturity increases.

In this blog, we will introduce our recommendations for the ten base principles of an EDA manifesto. For further inspiration, we recommend the subjects that we discuss in our two blogs about common pitfalls during EDA implementations. For now, let’s get started with the basics!

1. Think business first

An Event-Driven Architecture is centred around business events that capture an organisation's behaviour and trigger other business processes. Business events are valuable and easily understandable for business users because they reflect what happened. That’s why it’s important to ensure that every designed event is business-oriented and accurately reflects the organisation's business environment.

2. Single writer principle

When implementing an Event-Driven Architecture, it's essential to ensure that each application is responsible for one or more business domains. No other application should interfere with this responsibility, as it can lead to ambiguity and confusion. To achieve this, domain-driven design can help define the bounded contexts and domains of each application. Additionally, each topic should only have one application producing events to maintain consistency and prevent conflicts.

3. Think about long-term storage

Behavioural data captured by business events can be highly valuable for an organisation in the long run. By storing these events for a long time, the data can be used to phase in new applications more easily, add real-time analysis, run simulations, and much more. Therefore, it's essential to plan for long-term storage and accessibility of business events when designing an event-driven architecture.

4. Topics and event schemas define the contracts

Just like APIs, events in an Event-Driven Architecture are defined by a contract. This includes the topic name on the event hub, the properties in the event header, and all field names in the payload. To ensure clarity and consistency, it's important to express these elements in the language used by the business.

This principle also applies to user interfaces and backend coding. When everyone speaks the same language, working together becomes more efficient, and the likelihood of bugs decreases.

5. Versioning ensures compatibility and smooth upgrades

When creating event schemas, it's important to consider forward, backward, or full compatibility. The compatibility level can impact your deployment strategy and the ability to upgrade schemas without breaking changes. If a breaking change is required, a new topic with the version included in the name should be created. This allows consumers to switch to the new version during a grace period.

Ideally, this switch can be facilitated with a stream between the old and new versions of the data contract. By implementing versioning, you can maintain the consistency and integrity of your event-driven architecture over time.

6. Empower teams with autonomy

In an Event-Driven Architecture, it's important to ensure that teams are responsible for one or more bounded contexts or topics, and are able to work autonomously. Clear governance and rules can help to ensure that events are produced and consumed as expected. This autonomy allows teams to innovate and make decisions that best fit their domain while staying true to the overarching principles of the EDA.

7. Keep it short and simple

When designing events, it's important to keep it simple. The granularity of events should be considered and named in a way that accurately reflects what happened, and in a language that is easily understandable by business users. Domain-driven design principles, such as context mapping, subdomains and aggregates can help achieve this.

The consuming or streaming logic must always be easy to understand. The streaming should be done within the context of one component or bounded context and step by step.

8. Stay focused on the end-to-end process

In an Event-Driven Architecture, every event is a step in a larger process. It's crucial for organisations to understand the sequence of events and have a holistic view of the end-to-end process. This makes it possible to identify potential bottlenecks, and helps with maintaining consistency and optimising the entire process.

9. Not everything needs to be event-driven

While Event-Driven Architectures are powerful, not every part of your system needs to be event-driven. Synchronous communication is still useful, particularly when integrating services within a bounded context or when the event in question wouldn't have any business value. Be mindful of where you use event-driven approaches and where synchronous communication may be more appropriate.

10. Both ways of producing events are valid

There are two approaches to producing events: event sourcing and database-centric. With event sourcing, events are at the core of everything, and the state/database becomes a read model created by consuming events. One of the benefits of this approach is that you can recreate the state on the fly.

With a database-centric approach, the application's database remains the master, and events are published as they occur. It's important to consider transactions and the outbox pattern when using this approach.

Conclusion

Event-Driven Architecture is a powerful approach to designing and building modern, scalable, and resilient systems. EDA enables organisations to capture, process, and respond to business events in real time, leading to improved agility, efficiency, and decision-making. By applying the base principles of our EDA manifesto, businesses can go a long way, but we recommend adding principles based on our other blogs and their specific needs.