What are the Saga design pattern and types available?
The Saga Pattern is a microservices architectural pattern to implement a transaction that extends multiple services.
A saga is a sequence of local transactions. Each service in a saga performs its own transaction and publishes an event. The other services listen to that event and perform the next local transaction. If one transaction fails for some reason, the saga also executes compensating transactions to undo the impact of the preceding transactions.
Example:
Consider a Food delivery service flow, When a user places an order, below could be the flow.
The food ordering service creates an order. At this point, the order is in PENDING status.
With the Saga pattern, it contacts the restaurant via the restaurant service.
The restaurant service attempts to place an order with the selected restaurant, Once the order is received by Restaurant it sends back an ORDER_ACCEPTED (if the order is accepted) or ORDER_REJECTED (if the order cannot be accepted) status.
The saga received the status ORDER_ACCEPTED or ORDER_REJECTED status and process the response to the customer accordingly.
The food order service then changes the status of the order, if the order is accepted then it displays an order confirmation message if the order is rejected it display an apologies message and suggest alternative restaurants.
Types of Saga:
Orchestration-based saga
Choreography-based saga
In the next article, we will see in detail about the Type of Saga design patterns.
Before understanding what is Event sourcing design pattern is, let us see why & when do we use the Event sourcing design pattern.
All application uses data to maintain the current state of the data by updating it, In the traditional Create, Read, Update & Delete (CRUD) model a data is read, then make some modification to It, and update the current state of the data with the new values – often by using transactions to lock the data.
CRUD has its own limitations, below are a few such limitations.
CRUD performs update operations directly against the data, which slowdowns the performance and limits the scalability.
When multiple users read and updates the data, more likely conflict occurs since the update operations take place on single data.
Unless there is a separate auditing mechanism that records the state of data as history or the state of the data is lost.
Now, this is why & when we need to use an Event sourcing design pattern.
Event sourcing design pattern:
Event Sourcing gives us a new way of persisting application state as an ordered sequence of events. We can selectively query these events and reconstruct the state of the application at any point in time. Of course, to make this work, we need to reimage every change to the state of the application as events:
Event sourcing design pattern
Example:
Consider we have Order and Cart services, When the Client adds the item to the cart or remove the items from the cart, these are called events, These events must be stored in order to maintain the changes made to the cart.
The events are persisted and published into the Event queue. Where the other services will subscribe to those events to get the updated state of the cart.
Consider you add the item to cart from Mobile App, then you login to website via PC and make some changes to the cart, these are captured as events and maintaining the seamless experience when accessing the cart in different platform.
In the next article, we will see the Branch design pattern.
For every web service application, there is a massive amount of data present. So when the application is broken down from monolithic to microservice, It is necessary that each application have a sufficient amount of data to process the request.
So, we can have a database for each service or it can have a shared database.
Yes, we can use a database per service or shared database to solve many problems.
Below are a few of the problems,
Data duplication and inconsistency
Different application has different storage requirements and different infrastructure.
Few transactions can query the data with multiple services.
De-normalization of data
In order to solve the first 3 problems, we can go for database per service, as it will be accessed by the microservice API itself.
So each web service will have its own databased ID, which the other services do not have direct access to.
📌 Note: Limit the number of databases to 2-3 for the microservices; else, scaling up will be a problem.
Shared Database Design Pattern: Example
Example:
Example1: Partially having a shared database for the microservices.
In the above image, If you see the Contact & Student services shares a database but whereas Fees has its database. (While designing the MSA for the application we can decide about how our application can utilize the database).
Example 2: Partially having a shared database for the microservices.
In the next example, if you see the image, the entire microservices uses the one common shared database. this way the database is one and multiple services use it to persist or read data.
In the next article, we will see Asynchronous Messaging design pattern.
Today we will see what is Asynchronous Messaging Design Pattern is.
What is Asynchronous Messaging Design Pattern?
Previously we saw about Chained or Chain of responsibility design pattern which makes the client wait for a long time, It also breaks the chain if any one service goes down and cause a bad experience for the clients.
To avoid such bad experiences for the client, The Asynchronous design pattern can be used, which communicate with the available services using message queue or event driven approach and not sequentially.
Yes, Messaging or events, The Asynchronous design pattern uses the Messaging Queue (MQ) or Event driven like ActiveMQ, RabbitMQ, Kafka and other tools for its communication with other services.
Example:
Consider we have Cart, Product, Stock, Order & Shipping services.
When the Product is added to the Cart, Stock must be updated accordingly, So the Product calls stock via Message Queue.
And then Order calls shipment via Message Queue to prepare a label for shipment.
This way the client need not wait for the flow of service to be completed to get the response immediately.
In the next article, we will see Shared Database or Shared Data design pattern.