I think you are looking for "BASE" (Basically Available, Soft state, Eventual consistency). BASE is usually regarded – or least proposed – as an acceptable alternative to ACID for distributed databases.
I like this explanation from ACID vs. BASE:
- Basically Available: This constraint states that the system does guarantee the availability of the data as regards CAP Theorem; there will be a response to any request. But, that response could still be ‘failure’ to obtain the requested data or the data may be in an inconsistent or changing state, much like waiting for a check to clear in your bank account.
- Soft state: The state of the system could change over time, so even during times without input there may be changes going on due to ‘eventual consistency,’ thus the state of the system is always ‘soft.’
- Eventual consistency: The system will eventually become consistent once it stops receiving input. The data will propagate to everywhere it should sooner or later, but the system will continue to receive input and is not checking the consistency of every transaction before it moves onto the next one. Werner Vogel’s article “Eventually Consistent – Revisited” covers this topic is much greater detail.
About Consistency on the distributed database, from the paper "Notes on Distributed Databases":
Transactions in a distributed environment can archive the appearance that all data is stored as a single copy at a single site. For data which is not replicated is has been shown that a distributed database management system need only obey the rules for non-distributed database management:
- Lock entities before using.
- Hold all locks until end of transaction.
For replicated data, two additional principles are required in order to archive single site, single copy equivalency:
- Updates must be broadcast to all replicas before the transaction ends.
- If updates are not immediately broadcast and performed by replicas, then all accesses after an update must be to an updated copy.
It has been shown that these four conditions are sufficient to guarantee the equivalent of a single copy, single site, serial user system.
The linked paper discusses various update strategies and distributed transaction management among other things.
Whatever or not we require all nodes to agree on the transaction to consider it completed is an implementation detail. BASE only requires that the nodes will eventually agree at some point after the transaction completed.
About consistency as in CAP. BASE does not guarantee that the most up to date value will be returned. Only that if no more writes happen and the client keeps reading, it will eventually get the most up to date value. That is, the reads could be looking at a state that lags behind. Yet that state is valid, the atomic nature of transactions is preserved.
The flip side is that BASE does not require the data to be replicated to all nodes to return it either. Depending on the implementation, it could be possible that the most up to date value is returned to a client while it has not been replicated to all nodes.