In recent years, from the alley to the front, family members have heard the good news from far away and want to experience the beauty of the rose "microservices". I am also a resident living in that small alley, fortunate to have the opportunity to experience Microservices. However, many times I stuck with the requirement of its consistency and data integrity.

Why stuck? When working with a monolithic system or a service, I operate on a database (db), here with micro, one db for each service (database per service), ensuring data consistency between dbs is extremely difficult.

Saga pattern was born to solve that problem. If someone asks you what is the Saga pattern? Then you can say that Saga is a collection of transactions of services linked together to fulfill a request from business. During execution, if a transaction from a service fails, all will be returned to their original state.

It sounds too cumbersome, I would like to take a simple example from the function of creating an order of the e-commerce system to illustrate.

When the user creates an order, the Order service will write a new record to the db, then the Inventory service will update the inventory quantity, and finally the Shipment service will create a shipping order. It won't hurt if the load is broken in the middle of the road, the bad luck of the shipment service without rolling back the data is extremely strong. Saga offers two extremely effective healing potions: Choreography-based saga and Orchestration-based saga. So what is the difference between these 2 doses?

• Choreography: services negotiate with each other.
• Orchestration: there is a chairperson to solve the problem

Saga meets ACDs principle (lack of I)

• Atomicity: data from a service is dead system-wide, rollback to the original state
• Consistency: data of the whole system between services is consistent
• Durability: The chairperson (Orchestrator service) can backup events from message-broker (kafka)

Next, I will use Orchestration-based saga to build an application to illustrate the feature of creating order orders (for the example above).

I will use Kafka as a message-broker, built on Kafka confluent cloud free including 3 main topics corresponding to 3 services:

• Order Service
• Inventory Service
• Shipment Service

async function runTransaction() {
  const sagaBuilder = new SagaBuilder()
    .route('ORDER_SERVICE')
      .invoke(async () => {
        await axios.post('http://order-service/api/v1/orders', seedProduct)
      })
      .rollBack(async () => {
        await axios.put('http://order-service/api/v1/orders/2', { status: 'INACTIVE' })
      })
    .route('INVENTORY_SERVICE')
      .invoke(async () => {
        await axios.put('http://inventory-service/api/v1/products/1', { type: 'INVOKE' })
      })
      .rollBack(async () => {
        await axios.put('http://inventory-service/api/v1/products/1', { type: 'ROLLBACK' })
      })
    .route('SHIPMENT_SERVICE')
      .invoke(async () => {
        // console.log('Create shipment...');
        throw new Error('Something wrong')
      })
      .rollBack(async () => {
        console.log('Roll back to Shipment Service API');
      });

  const sagaProcessor = await sagaBuilder.build()
  sagaProcessor.start({ id: 1 })
}

When starting to run the transaction, the orchestrator will coordinate to each topic message, then go to trigger the data of the corresponding service, if during the execution process fails in a certain service, the system will rollback the data as before.

Github repo: https://github.com/lequocduyquang/saga-microservices

Above are the insights that I gathered and experienced when I collided with the Saga pattern. The article certainly has a lot of shortcomings, I hope everyone can contribute and share so that I can learn and improve. Thank you so much to everyone who took the time to read my post.

References:

• Blog: Saga - Microservices.io
• Book: Microservices Pattern - Chris Richardson - Chapter Saga