Microservice accessing DB through another microservice while maintaining ACID guarantee

Question

Please help me understand this data sharing concept related to micro-services, I am trying to learn the best practices.

Suppose I have a Lambda function (micro-service) A that is designed specifically to perform CRUD operations on a DynamoDB table (NoSQL). I have use cases that trigger this function to update specific items in the table.

I have another micro-service B that will need to read and write to the same database table. If I were to have this micro-service B directly perform CRUD on the DynamoDB table, that would be a bad idea since now A and B are both configured to operate separately on the table so ACID guarantee is lost. (correct?)

To prevent this, would this be the best solution? :

• Get rid of micro-service B altogether.
• Whatever event would have triggered B, have it trigger A instead to perform the corresponding database CRUD operations.

Would this maintain ACID guarantee?

Answer 1

I'm not sure how 2 microservices violate ACID properties. Below are the properties and a description of how having multiple producers affects it.

Atomicity

Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged.

• Having two producers does not break Atomicity

Consistency

Consistency ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof.

• Having two producers does not break Consistency

Isolation

Transactions are often executed concurrently (e.g., multiple transactions reading and writing to a table at the same time). Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.

• I think you believe Isolation is where your issue is, however all writes to DynamoDB are strongy serializable and thus isolated

Durability

Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or crash).

• Having two producers does not break Durability

Wiki

Answer 2

If I understand your question correctly it is not about microservices or ACID but more about data consistency in general. And again if my assumption correct your question should be like "how could I make sure data is consistent when several client - regardless if they are in the same process or different - tries to read and update the same data (document, row)?"

There are couple of strategy to deal with this depending on the requirements.

• If the persistence technology you use support you may use some data locking mechanism with severe side effects or

• you may try to use an optimistic lock implementation which may require some changes in your use cases.

• Having said that I don't think you can guarantee such consistency even if you have just one single microservice as you may need to scale it by having at least 2 instance for the sake of resilience and high-availability. If for some reason you can afford to have a single instance of a service then you may set this single service as only writer and apply some thread syncronization on the application level.

If my initial assumptions are false please ignore all of those above.