Event Driven Architecture
Last updated
SC - Software Architecture
Last updated
An -oriented or -driven architecture, is a solution for distributed in a Microservice environment having:
Low coupling;
Asynchronism (With );
Without the need of an .
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.
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.
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.
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 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.
Commands are solicitations, and eventually can be rejected.
Involves separating a solicitation that was synchronous in 2 steps.
One that receives the command.
The second one that process the command.
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.
With plataforms like:
RabbitMQ
Kafka
AWS SQS
ActiveMQ
Google Pub/Sub
ZeroMQ
Pulsar
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.
When encountering unavailability during execution, this pattern helps by trying another service.
This pattern is responsible for managing long duration transactions, by using a sequence of local transactions.
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.
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.
Can be locally done in the code with help of and .
Same essence of .
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.
