Transaction management of the microservices

Question

I am new one for the microservices. Can you please explain about the transactional management of the microservices and how is work the foreign keys between the different databases as an example client and order services has their own sevices and databases. If we use single database, order table has a foreign key of client. But databases are different how we put the foreignkeys between this tables? And how we done the transaction management between this services? Thank you

Answer 1

Distributed data management in the world of micro services is one of the most complex problems to solve. However there are patterns and guidelines that help in addressing the issues with distributed data. Some of them are listed below

1. Define the Bounded context of the micro service - Each microservice must own its domain data and logic. This is where you need to break foreign key dependencies and identify which table you will own and which you will reference.

2. Eventual consistency over ACID semantics - If there are two services Catalog and Basket. Catalog contains the product details and Basket contains the item purchased by a user currently. Any change in product price should be reflected in items in basket. However since the product data and Basket items are stored in two different databases the price update happens asynchronously. This could be via a publisher subscriber pattern. For example a price change event is published on message bus and services like Basket subscribes to it and updates itself when it receives the event.

3. Read only data stores using materialized view - This is a form of CQRS pattern where data from multiple services is stored in a de-normalized form in read only data store. The data gets updated asynchronously using the approach mentioned above. The consumers gets fast access to data without having to query multiple services.

So in summary for CAP theorem microservices world prefer high performance and scalability and availability over strong consistency. The consistency is resolved eventually using asynchronous communication.

https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/distributed-data-management

Answer 2

It looks to me that you are trying to address eventually consistent world by ACID standards. Normally the reason to have microservices is because ACID will not scale, otherwise why to have multiple databases? At this point, you should sort of forget about transactions and be very clear about responsibilities of each microservice and what data it handles. Try to use very clear keys that key be logically foreign keys between services, but it's not enforced.

So for example you have two services: StudentsService that handles operations on the students and ScheduleService that handles students' schedule.

StudentsService will have students database that can allow multiple searches of students, etc. One important field this service should assign to each student - unique id. At very least the StudentsService should provide the following APIs:

• Retrieve student id by email
• Retrieve student id by phone
• Retrieve student by id.

Now ALL other services must use student id as identifier for the student. They don't understand the field. They don't know if it's real or not (foreign key implies the check that it's real, but is it really important?)

And now you sort of have your foreign keys, but not really.

Given that student's unique id must never change - there must be no reason to change it ever. And given that it is never deleted (storage is cheap nowadays), you have a perfect foreign key.

Transactions are tricky and should be avoided at all cost if you want to scale. Why do you want transactions? Can you have a flow of small idempotant operations that client can retry or fail fast? Continuing the above example, editing or creating a student will be one operation, while creating or editing a student schedule can be another one. No transaction needed between the two.