The main questions this article will answer:
- How to persist data in microservices architecture?
- How to get a complex job done in a microservice architecture?
The main idea behind the term Eventual consistency in the microservices world is understanding the best way to complete a complex task is to break the task into smaller tasks and have people independently work on these sub-tasks.
Scenario
Let us imagine an order management system, a microservice communication is applied between an order-service, payment-service, and stock service to fulfill this job.
When a customer places an order, let us assume that the order first goes to the stock service for stock control and availability check. After that, the order is forwarded to the payment service in order to get the money from the customer's visa card. The final step is to insert this order into the database as a record through the order service.
Assuming that an issue occurred in the order service, and the final step is not being completed at that specific timestamp. A data consistency issue occurred.
Approaches to resolve such issues
The question that should be asked in the above scenario is if such an error occurs in the process, Should the whole process be rollbacked?
There is no right approach to choose, it depends on the use case of the process.
1. The first possible solution might be 2PC (two-phase commit).
two-phase commit: In transaction processing, databases, and computer networking, the two-phase commit protocol (2PC) is a type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction.
This technique ensures strong data consistency, but at the same time, it has some drawbacks such as low latency and throughput, slow since it is blocking, and might achieve transactions deadlock.
2. Eventual consistency
Eventual consistency is a technique that ensures data consistency and availability by asynchronous communication and ensuring that when an error occurs in a specific process, the error will be resolved eventually without having to roll back the whole process.
Eventual consistency can be achieved by asynchronous and event-driven communication between microservices via messages and events brokers.
Going back to the example we explained earlier. Every action in the process is basically an event that will be pushed to a certain queue. Each microservice will subscribe and listen to its respective queue. When an error occurs just like the one above, the event will be stored in the queue. And this particular microservice will keep retrying to consume the event until it consumes it successfully and reach the completion state.
This approach can not be achieved with synchronous communication via REST, because REST can not persist events or requests.
References:
Top comments (0)