Microservice architecture - how to implement transactions?

Question

Service Oriented Architecture

Good afternoon.
I decided in my free time to design and then implement a service-oriented project in order to study the approach. I began to figure out the approximate software that will be used.

But one question haunts me and which I don’t understand: data integrity during service component crashes. Here, a message queue must be implemented through a cross-platform protocol for sure. For example, AMQP.

1) How are transactions implemented in this case? AMQP seems to have two kinds of transactions, but as far as I understand, they all offer queued message transactions. What about the data that may already be entered into the database? Or does the protocol transaction cover that?
2) What happens to the message if the service is, say, stuck on a deadlock? Is it possible to repeat the processing of the message by the service?
3) If the two questions are damn stupid, then the question arises - how to implement transactions correctly? Distributed transactions could be an option if it were not for the condition that databases in such an architecture can be different and not all of them have decent support for distributed transactions.

Answer 1

Oh, and a sensitive topic. And there are too many questions, each of which must be considered separately. In short, the topic of this question is googled as Distributed Transactions. The basis of distributed transactions is the orchestration of microservices and the Saga Pattern. It is really organized through queues, but most often they are hidden under the hood of Workflow Manager (Zeebe, AWS StepFunctions, ...) ...
Data integrity in distributed systems is never 100%. Rather, there are moments in which this happens, but it is rather a miracle. Additional mechanisms involved in their background audit are responsible for checking the consistency of data.
The easiest way to solve the unavailability of services is through the Circuit Breaker Design Pattern.