Event-Driven Architecture

Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an architectural style centered on discrete services. In this approach, a system is viewed as a collaboration of well-defined services.

Consider a user management system as an example. Initially, an Account Service is responsible for creating new accounts. A User Service then provides an interface for adding the corresponding user records.

If we later introduce a feature allowing users to delete their accounts, the User Service expands to include an interface for deleting existing users.

The system evolves as its services expand and take on more responsibilities. This demonstrates how services are central to building a system using SOA.

Event-Driven Architecture (EDA)

An event represents a business fact that has occurred within the system, such as an order was created or an order was cancelled. In theory, the sequence of events reflects how a business evolves.

From this perspective, Event-Driven Architecture (EDA) advocates evolving a system around its events.

In our user management example, a UserCreated event is triggered when a user registers an account. A UserCreated Handler then handles this event and adds the corresponding user record.

When the ability to delete users is introduced, a UserDeleted event is introduced to support this requirement. A new UserDeleted Handler is then developed to handle this event.

Events are at the core of an EDA system. The business is modeled as events and their transformations; the system, comprising consumers and producers, is then developed to produce and handle these events.

Event Collaboration

It is common for actions to involve multiple services. For instance, when a new account is registered in the Account Service:

1. The User Service creates a new user record.
2. The Notification Service sends a welcome email.

Orchestration

The first approach involves introducing an orchestrator service, such as the Account Service, which performs these tasks sequentially.

Because everything is centralized and clearly defined in one place, this approach is easier to understand and control, particularly for managing complex interactions. However, the orchestrator introduces dependencies between services and becomes a Single Point of Failure , potentially reducing overall system availability and fault tolerance.

Choreography

Conversely, choreography is an approach that relies purely on events:

1. The Account Service emits AccountCreated events.
2. The User Service consumes these events and, in turn, produces new UserCreated events.
3. The Notification Service then consumes UserCreated events to send welcome emails.

In an EDA system, asynchronous communication is preferred. This enables different parts of the system to react to events independently, promoting loose coupling and fault tolerance.

However, this approach can become difficult to manage in complex workflows. This complexity is the most significant challenge of EDA. A single business operation might involve a long chain of events, produced and handled in many different parts of the system. This makes it difficult for developers to fully understand the business process and develop the system effectively. The complexity is particularly pronounced in large systems, which may handle a vast number of events (potentially hundreds or even thousands).