38
loading...
Microservices Architecture: Event Sourcing and Saga Pattern
Organizations continuously seek new approaches to build growth opportunities and reduce marketing time. One can increase their organization’s efficiency and agility by application or software modernization. Application modernization is a gateway to continuously improve your organization by refactoring a monolithic application into a set of independently developed, managed and deployed microservices.
Although you can use monolithic applications for a few use cases, modern features usually don’t work in an application based on monolithic architecture. Monolithic applications can become large and unmanageable that require coordination and effort from multiple teams, even if a small change is needed.
That’s why by choosing microservices you can decentralize your data stores and promote polyglot persistence among different microservices while detecting your data storage technology depending on the data access patterns and other microservices requirements.
However, this decentralized polyglot persistence can also lead to eventual data consistency and other challenges that need a thorough evaluation. So, in this article, we will check out the two popular patterns of microservices architecture, namely, Event Sourcing Pattern and Saga Pattern.
In the traditional CRUD (create, read, update, and delete) model a typical data process is to read from the store, make some changes and update the current data state with the new value using the transaction that locks the data. Due to the required process overhead, this approach has some limitations like slower performance, limited scalability and reduced responsiveness.
That’s where the event sourcing pattern comes into view. It is often used with CQRS Pattern to decouple read and write workloads from each other and optimize them for better scalability, performance, and security. It is an approach where we can get all the application state changes as a sequence of events. The data here is stored as the number of events rather than directly being updated in the data stores. Event sourcing is an excellent method to update the business entity or application’s state and publish the events automatically.
In the event sourcing pattern, the application code sends a series of events that crucially describes each action that has taken place on the data to the event store. The events are persisted in an event store that acts as the record system of the current data state. Then the event store publishes the events to notify the users and handle them if required.
So what are the advantages of the event sourcing pattern and what’s the reason you should be using it? Let’s check it out!
1. Events don’t update a data store directly instead they are simply recorded for handling at a suitable time that can simplify the management and implementation.
2. Events are changeable and can be stored using an append-only operation. The user interface process or workflow that has created an event can continue while tasks handling events run in the background. Moreover, no contention at the time of transaction processing can help in enhancing the scalability and performance of the application, particularly for the user interface.
3. As event sourcing can avoid the need to directly update an object in the data store, it helps to outdo the concurrent updates from creating conflicts.
4. The event source initiates an event and performs task operation in response to that event. With this decoupling of the task, we can easily achieve extensibility and flexibility in the application.
There are multiple scenarios where event sourcing patterns can be used. So, here is the list of a few of them you should know about.
1. Event sourcing patterns can be used when it’s important to minimize the existence of conflicting updates to data.
2. It can be used to record an event that has taken place and be capable to replay them and restore the state of a system, keep history, roll back changes and audit logs.
3. Event sourcing pattern can also be used in conjunction with CQRS for eventual consistency that allows the read model to be updated or the performance of rehydrating entities and data from the event stream to be impacted.
4. It can be used to increase the flexibility to change the format of entity data and materialized models.
The saga pattern is the failure management pattern that allows the establishment of consistent distributed applications. It helps in the coordination of transactions among multiple microservices in order to maintain the consistency of data.
Saga is a sequence of transactions that updates every service and announces a message or event to trigger the next step in the transaction. If somehow a step fails, the saga pattern executes a transaction that compensates to prevent the preceding transaction.
It provides transaction management through a sequence of local transactions (that’s an atomic work effort conducted by saga participants). Each local transaction updates the database and proclaims an event or message to trigger the next local saga transaction. In saga patterns, compensable transactions potentially reverse the transaction that fails by processing other opposite effect transactions, retriable transactions guarantee the success of the events and pivot transactions are a go or no-go point in a saga that runs until the completion of the transaction. The pivot transaction is neither retriable nor compensable.
The saga pattern is of two types: choreography and orchestration. A choreography saga pattern is a method to organize sagas where participants swap events without a centralized control point. On the other hand, an orchestration saga pattern is a method to coordinate sagas through a centralized controller that informs the saga participants what local transactions should be executed. It handles every transaction and determines the operation needed to be performed by a participant based on events.
1. The orchestrator saga pattern is good for the complex workflow that involves various participants.
2. It will be suitable when every participant and activity flow is controlled in the process.
3. Whereas, the choreography saga pattern is beneficial for simple workflows having few participants.
4. It doesn’t require additional service maintenance and implementation and doesn’t introduce a single failure point as the responsibilities are distributed among the participants.
Majorly this pattern can be used when you need to ensure data consistency without tight coupling in the distributed system or microservices. It can also be used when there is a need to roll back or compensate for the operation in the case of sequential failure.
So with the understanding of the basics and benefits of both event sourcing and saga pattern, you will be able to decide which one will be more beneficial for your microservices architecture needs.
So with the understanding of the basics and benefits of both event sourcing and saga pattern, you will be able to decide which one will be more beneficial for your microservices architecture needs.
Source: Decipher
38