Event Driven Architecture

About

An event-oriented or event-driven architecture, is a solution for distributed transactions in a Microservice environment having:

• Low coupling;

• Asynchronism (With Queues);

• Without the need of an orchestrator.

Tecnically only used in a Microservice Architecture.

Advantages

• Low coupling between Usecases inside and outside of a service.

• Fail tolerance with the capacity if returning from where it stopped.

• More control over technical debt.

• Higher availability and scalability.

• Lower costs with infrastructure.

• Better understanding over what happened, with possibility of PITR.

Disavantages

• Higher technical complexity.

• Must deal with event duplication.

• Lack of workflow clarity.

• More difficulty in treating and diagnosing errors.

What is a Transaction

It is an abstraction of a set of operations that must be treated like a single logical unit, where either:

• ALL of the Transaction operations succeed.

• Or everything is undone.

Ex.: Concept of ACID for relational databases.

The more complex and distributed an Architecture is, the greater the changes of bad things happening.

So resilience is the ability to keep it running and recover from failure.

Example

In a distributed environment, not every operation of a Transaction are for Databases. (You could have operations that check files, or external APIs, or Different DB types, or has to wait for a scritp to calculate something, etc...)

So in these chained distributed environments, what happens if we have a fatal error in the middle of a Transaction?

Events

Events are facts that happened in the Domain and can be a trigger to execute business rules.

Events are facts that were published and must be consumed/treated.

Ex.: OrderPlaced, PaymentApproved, InvoiceGenerated, RideRequested, RideEnded, ...

Commands

Commands are solicitations, and eventually can be rejected.

Command Handler

Involves separating a solicitation that was synchronous in 2 steps.

• One that receives the command.

• The second one that process the command.

Queues

They exist to balance resource availability with resource demand. Since there isn't always enough available resources, and it would be too expensive to have it, we can queue demand.

Queuing demand avoids waist of resources, because of peak behavior of demand.

Implementing Queues

Locally

Can be locally done in the code with help of Mediator and Observer.

Externally

With plataforms like:

• RabbitMQ

• Kafka

• AWS SQS

• ActiveMQ

• Google Pub/Sub

• ZeroMQ

• Pulsar

Patterns

Retry

Retry pattern simply makes one or more retries in a small time interval.

They can resolve simple problems like package loss, network oscillations and even a out of time deploy.

Fallback

When encountering unavailability during execution, this pattern helps by trying another service.

Ex.: E-commerces work with several credit card services to avoid unavailabilities.

Same essence of Chain of Responsibility.

SAGA

This pattern is responsible for managing long duration transactions, by using a sequence of local transactions.

They are not necessarily related to microservices, and can be applied to any type of long duration distributed transaction.

SAGA has 3 types of Transactions

Pivot Transaction

• They are go or no go transactions.

• These are transactions that decide if entire flow of execution goes forward or gets aborted.

Compensable Transaction

• These transactions are undone in case the entire transaction is aborted.

Retriable Transaction

• These have a guarantee of execution.

• They can recover from a possible fail or unavailability.

Orchestrated SAGA

In these types of SAGA, there is a centralized logic that coordinates each of the steps.

Easier to see/understand the workflow.

As a drawback, it is highly dependent in this central orchestrator.

The orchestrator knows which step he is supposed to call next, even on failures.

This centralized logic could be in the simpler way, just a script that can call each step and a database table that holds which step of the entire Transaction it is in.

Choreographed SAGA

In these types of SAGA, each participant publishes and treat events independently, deciding if it should continue or not the flow.

As a drawback, it may be harder to see/understand the workflow.