Microservices with Dot net Core 3.1.1 and Docker

Hi All, Welecome to WishTech this is Dev, Today i am going to show you how to use micro services in our real world project and it's benefits in our developers life.

An important rule for microservices architecture is that each microservice must own its domain data and logic. Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. This means that the conceptual model of the domain will differ between subsystems or microservices. Consider enterprise applications, where customer relationship management (CRM) applications, 

transactional purchase subsystems, and customer support subsystems each call on unique customer entity attributes and data, and where each employs a different Bounded Context (BC). This principle is similar in Domain-driven design (DDD), where each Bounded Context or autonomous subsystem or service must own its domain model (data plus logic and behavior). Each DDD Bounded Context correlates to one business microservice (one or several services). This point about the Bounded Context pattern is expanded in the next section. On the other hand, the traditional (monolithic data) approach used in many applications is to have a single centralized database or just a few databases. This is often a normalized SQL database that’s used for the whole application and all its internal subsystems, as shown below image

Data sovereignty comparison: monolithic database versus microservices

the catalog business microservice could be composed of several services or processes. These could be multiple ASP.NET Web API services or any other kind of services using HTTP or any other protocol. More importantly, the services could share the same data, as long as these services are cohesive with respect to the same business domain.

                                         Business microservice with several physical services

Saga Pattern Using Microservices.

The Saga Pattern is one of the 6 Important Data Management Patterns of microservices. At it's very core, the Saga Pattern can be seen as a direct result of the database-per-service pattern.

In the database-per-service pattern, each microservice is responsible for its own data. However, this leads to an interesting situation. What happens when a business transaction involves data that spans across multiple microservices?

That is where the need for the Saga Pattern arises. 

What Is the Saga Pattern?

The Saga Pattern is as microservices architectural pattern to implement a transaction that spans 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.

Let's see a simple example in a typical food delivery app flow.

When a user places an order, below could be the sequence of actions that happen.

• The food ordering service creates an order. At this point, the order is in a PENDING state. A saga manages the chain of events.
• The saga contacts the restaurant via the restaurant service.
• The restaurant service attempts to place the order with the chosen restaurant. After getting a confirmation, it sends back a reply.
• The saga receives the reply. And depending on the reply, it can approve the order or reject the order.
• The food order service then changes the state of the order. If the order was approved, it would inform the customer with the next details. If rejected, it will also inform the customer with an apology message.

As you can see, this is a pretty different approach from the usual point-to-point call approach in typical workflows.

Types of Sagas

There are two types of Sagas:

Orchestration-Based Saga

In this approach, there is a Saga orchestrator that manages all the transactions and directs the participant services to execute local transactions based on events. This orchestrator can also be though of as a Saga Manager.

Choreography-Based Saga

In this approach, there is no central orchestrator. Each service participating in the Saga performs their transaction and publish events. The other services act upon those events and perform their transactions. Also, they may or not publish other events based on the situation.

(Event Based)Choreography-Based Saga

Advantages and Disadvantages of the Saga Pattern

The main benefit of the Saga Pattern is that it helps maintain data consistency across multiple services without tight coupling. This is an extremely important aspect for a microservices architecture.

However, the main disadvantage of the Saga Pattern is the apparent complexity from a programming point of view. Also, developers are not as well accustomed to writing Sagas as traditional transactions. The other challenge is that compensating transactions also have to be designed to make Sagas work.

In my opinion, Sagas can help solve certain challenges and scenarios. They should be adopted or explored if the need arises. However, I would love to hear if others have also used Saga Pattern and how was the experience? What frameworks (if any) did you use?