Event-Driven Architecture

Event-driven architecture (EDA) is an approach to software architecture that emphasizes the production, detection, and consumption of events as a primary means of communication between software components. In EDA, the system is composed of loosely coupled components that communicate through events. Events are notifications of significant occurrences, such as changes in state or the completion of a task.

There are two main styles of EDA:

Event notification

In this style of EDA, the event is a “thin” event that contains minimal information about the context of the event. It simply serves as a notification that something has happened, and it’s up to the interested parties to query the system for more information. In this style, the event does not carry any state or payload. The interested parties subscribe to the event and receive notifications when the event occurs.

Example

Let’s say we have a simple system that manages user accounts. When a new user account is created, we want to notify other systems in the organization about this event. We can use the event notification style of EDA to accomplish this.

In this case, the AccountCreated event will look something like below:

public class AccountCreated {
    private final String accountId;
    private final DateTime createdOn;

    public AccountCreated(String accountId) {
        this.accountId = accountId;
        this.createdOn = DateTime.now();
    }

    public String getAccountId() {
        return accountId;
    }

    public DateTime getCreatedOn() {
        return createdOn;
    }
}

In the event notifications style, notice how the event simply contains the user account ID and a timestamp indicating when the account was created.

Event-carried state transfer

In contrast, in the event-carried state transfer style of EDA, the event is a “fat” event that carries a lot more information about the context of the event. It contains a payload of data that represents the state changes that have occurred. This payload is used to update the state of the interested parties’ systems, eliminating the need for them to query the system for more information. In this style, the event serves as a means of transferring state between systems.

Example

public class AccountCreatedEvent {
    private final String accountId;
    private final String username;
    private final String email;
    private final DateTime createdOn;

    public AccountCreatedEvent(String accountId, String username, String email) {
        this.accountId = accountId;
        this.username = username;
        this.email = email;
        this.createdOn = DateTime.now();
    }

    public String getAccountId() {
        return accountId;
    }

    public String getUsername() {
        return username;
    }

    public String getEmail() {
        return email;
    }

    public DateTime getCreatedOn() {
        return createdOn;
    }
}

Notice how the event now contains all the information about the user account, including their name, email, username, and any other relevant information.

Both styles of EDA have their advantages and disadvantages, and the choice between them depends on the specific requirements of the system.

Pros and cons

Here are some of the pros and cons of event notifications and event-carried state transfer styles:

StyleProsCons
Event Notification– Simple and lightweight
– Separation of concerns
– Loose coupling between components
– May require additional network calls
– Limited information in events may require additional queries to obtain necessary context
– May require additional coordination for ordering of events
Event-Carried State Transfer– Richer context in events
– Reduced need for additional queries
– Enables event sourcing
– Can support eventual consistency models
– Increased message size and complexity
– Tighter coupling between components
– Increased potential for data inconsistencies due to eventual consistency model
– May require additional coordination for ordering of events

See also

https://martinfowler.com/articles/201701-event-driven.html
https://www.enterpriseintegrationpatterns.com/docs/EDA.pdf
Chapter 2: Where and how does DDD fit? – Architecture Styles