ACID is an acronym for four primary attributes namely atomicity, consistency, isolation, and durability ensured by the database transaction manager. 

• Atomicity 

In a transaction involving two or more entities, either all of the records are committed or none are. 

• Consistency 

A database transaction must change affected data only in allowed ways following specific rules including constraints/triggers etc. 

• Isolation 

Any transaction in progress (not yet committed) must REMAIN ISOLATED from any other transaction. 

• Durability 

Committed records are saved by a database such that even in case of a failure or database restart, the data is available in its correct state. 

In a distributed SYSTEM involving multiple databases, we have two options to achieve ACID compliance: 

1. One way to achieve ACID compliance is to use a two-phase commit (a.k.a 2PC), which ensures that all INVOLVED services must commit to transaction completion or all the transactions are rolled back.
2. Use eventual consistency, where multiple databases owned by different microservices become eventually consistent USING asynchronous messaging using messaging protocol. Eventual consistency is a specific form of weak consistency. 

2 Phase Commit should ideally be discouraged in microservices architecture due to its fragile and complex nature. We can achieve some level of ACID compliance in distributed systems through eventual consistency and that should be the right approach to do it.