Event Sourcing and Saga Pattern In Microservices Architecture

I’m Arsalan Mirbozorgi;

In order to create new development opportunities and minimize marketing time, companies are constantly looking for innovative approaches. Application or software modernization can improve the efficiency and agility of a business. Refactoring a monolithic program into a group of independently built, maintained, and deployed microservices is an excellent method to enhance your organization continuously.

It’s possible to use monolithic programs for a few use cases, but most contemporary features aren’t supported. Even a minor update in a monolithic program can necessitate collaboration and effort from several teams, making it difficult to maintain.

Determining your data storage technology based on data access patterns and other microservice requirements is possible when using microservices to decentralize your data stores and enable polyglot persistence among various microservices.

Data consistency and other issues necessitate a careful assessment when decentralized polyglot persistence is used. The Event Sourcing Pattern (ESP) and the Saga Pattern (SAG) are two of the most commonly used microservices architecture patterns.

 

 

Basics and Advantages of Event Sourcing

It’s common practice to read data from a database using the usual CRUD paradigm, make changes, and then re-read the data to update it with the updated value. This solution has some disadvantages, such as slower speed, limited scalability, and reduced responsiveness, because of the required process overhead.

Event sourcing comes into play in this situation. CQRS Pattern is widely used to separate read and write workloads and optimize them for greater scalability, performance, and security by decoupling them from each other. All application state changes can be viewed as a sequential list of events. Rather than immediately updating the data storage, this data is stored as the number of events. Event sourcing is a great way to change the state of a business entity or application automatically.

Each action that occurs on the data is described in a series of events sent to the event store by the application code. As a record of the current data state, events are stored in an event store. Users are then notified of the incidents and can handle them if necessary.

 

Event Sourcing Pattern has many advantages

Why should you use event sourcing, and what are the benefits of this design in general? Let’s have a look at this!

• Instead of directly updating a data store, events are captured for handling at a convenient moment that simplifies the management and implementation of the system in question. 
• An append-only operation can be used to store changes to events. An event can be created while the user interface or workflow that generated it is still in use. Even more importantly, transaction processing can be improved by reducing the amount of conflict during this phase of the application’s lifecycle.
• To minimize conflicts caused by concurrent modifications, event sourcing avoids the need to update an object in the data store directly.
• The event source is responsible for initiating an event and then performing a job in response to that event. We may simply accomplish extensibility and flexibility in the application with this separation of the task.

 

Event Sourcing can be used for what?

A wide range of various applications can benefit from event-sourcing patterns. As a result, here are a few to keep an eye out for.

• There are situations where event sourcing patterns can be employed to avoid conflicting data updates.
• For example, it can be used to record an event, replay it, restore the system’s state, retain history, roll back modifications, and audit logs.
• When used in conjunction with CQRS, the event sourcing pattern can allow for updates to the read model or performance impacts on rehydrating entities and event stream data while maintaining eventual consistency.
• Using this feature can increase the ability to change the format of entity data and materialized models.

 

Basics and Advantages of the Saga Pattern

The saga pattern is a failure management technique that enables distributed applications to be established. Maintaining data consistency is facilitated by coordinating transactions among multiple microservices.

Saga is a series of transactions in which each service is updated, and the next step in the transaction is announced. Another transaction compensates for steps that fail in the pattern that prevents the previous transaction.

Using a series of local transactions (atomic work efforts carried out by saga players) provides transaction management. The database is updated each time a local transaction occurs, and the next local saga transaction is triggered by an event or message. A compensable transaction can potentially reverse a transaction that fails by processing other opposite effect transactions, retryable transactions assure the success of the events, and pivot transactions are a go or no-go point in a saga that runs until the transaction completes. Retrying or compensating for a pivot transaction is not an option.

Choreography and orchestration are examples of the saga pattern. Participants switch events without any central control point while using a choreographic saga structure. On the other hand, the orchestration saga pattern is a means of coordinating sagas through a central controller that tells the saga players what local operations they should perform. If a transaction is completed, it specifies what action is required of the participant.

 

Saga Pattern has many benefits

• Orchestrator saga patterns are ideal for multi-participant work processes.
• It will be appropriate if the process controls each participant and the flow of activities.
• On the other hand, the choreographic saga pattern is well-suited to workflows with fewer players and simpler requirements.
• A single failure point is not introduced because the obligations of the participants are divided. It does not require additional service maintenance and implementation.

 

Use of the Saga Pattern

Generally, this approach can be used to assure data consistency in a distributed system or microservices without tight coupling. In the event of a sequential failure, it can be used to roll back or compensate for the operation.

Understanding both event source and saga pattern’s basics and benefits will help you choose which one is best for your microservices architecture requirements.