microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it. Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api) and it has no knowledge about distributed transaction it rises some issues you have to deal with when something goes wrong: suppose u have microservice "make payment for item". When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work. If every part of this sequence succeded everything is good but the question is how to deal with errors, another api you are calling is unavailable, but your have changed state in many other systems, how to recover from there? is there some good approch to such situations?
2 Answers
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
In Microservice Architecture there is a pattern called "Saga" which covers the problem of distributed business transactions you described.
The Saga pattern describes a sequence of local transactions covered by different services. Each transaction is encapsulated in a service. If a local transaction fails because it violates a business rules then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
In general there are two ways to coordinate sagas:
The Choreography
In the choreography style of a Saga Pattern each local transaction publishes domain events that trigger local transactions in other services. This can be done by service calls or by sending events. It is usually the natural approach for the problem. The disadvantage of this method lies in the increasing coupling of the services, since often events have to be managed from a foreign domain.
If a business transaction is very short, a Choreography can be a good solution.
The Orchestration
Implementing a Saga Pattern with the orchestration style is a different approach where an orchestrator tells the participants what local transactions to execute. The orchestrator is also called the Saga Coordinator. This is were the business logic is placed. A Saga Coordinator calls services based on a declarative business logic and also handles the compensation in case of exceptions.
Workflow engines are a good approach to orchestrate different services within one business transaction. See also a description how you can use BPMN 2.0 to model the saga pattern here
Related