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
Externally
With plataforms like:
RabbitMQKafkaAWS SQSActiveMQGoogle Pub/SubZeroMQPulsar
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.
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
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.
Last updated
