How To Get Closer to Consistency in Microservice Architecture

When it comes to transactions, the first thing that comes to mind is ACID. Actually ACID is an important 4-point concept:

• Atomicity:  Each statement in a transaction (to read, write, update or delete data) is treated as a single unit. Either the entire statement is executed, or none of it is executed. This property prevents data loss and corruption from occurring if, for example, if your streaming data source fails mid-stream.
• Consistency: Ensures that transactions only make changes to tables in predefined, predictable ways. Transactional consistency ensures that corruption or errors in your data do not create unintended consequences for the integrity of your table.
• Isolation: When multiple users are reading and writing from the same table all at once, isolation of their transactions ensures that the concurrent transactions don’t interfere with or affect one another. Each request can occur as though they were occurring one by one, even though they're actually occurring simultaneously.
• Durability: Ensures that changes to your data made by successfully executed transactions will be saved, even in the event of system failure.

ACID makes sense in that every system has its own database and everything is in one module of codes.  However, in the microservice-based architectures, we have multiple loosely coupled modules where each one has its own database, transaction, and of course, ACID, but they are connected. There are still scenarios that involve multiple microservices, and the completion of the scenario depends on the completion of the tasks of each of these microservices. Ideally, all microservices perform their tasks correctly; but if one microservice fails, the whole scenario must be failed. Conceptually we need to have a general transaction between multiple independent microservices. 

from DZone.com Feed https://ift.tt/2ZdLddJ