ACID compliance in distributed systems is a major challenge because you’re trying to guarantee strong consistency across multiple machines, each of which may fail independently, lose connectivity, or process operations at different speeds.
🧪 What is ACID?
ACID stands for:
| Property | Meaning |
|---|---|
| Atomicity | A transaction is all-or-nothing |
| Consistency | The system moves from one valid state to another |
| Isolation | Concurrent transactions don’t interfere with each other |
| Durability | Once committed, the transaction survives crashes |
🔧 How Distributed Systems Handle ACID
1. Atomicity (A)
To make a transaction atomic across nodes:
- Use Two-Phase Commit (2PC):
- Prepare phase: All participants agree they can commit.
- Commit phase: If all say yes, the coordinator tells them to commit.
- ❌ Problem: blocking and coordinator failure.
- Or use Three-Phase Commit (3PC) (non-blocking but more complex).
Alternatives:
- Saga pattern (for long-running transactions): break big transactions into smaller, reversible ones.
2. Consistency (C)
Each node must validate its part of the transaction.
- Enforced via application-level invariants, foreign key checks, etc.
- Usually traded off for eventual consistency in AP systems (see CAP theorem).
3. Isolation (I)
- Hard to enforce strict isolation (e.g., serializable) across nodes.
- Often implemented via distributed locks, MVCC, or snapshot isolation.
- High-isolation levels reduce throughput and increase complexity.
4. Durability (D)
- Achieved via write-ahead logging, replication, and acknowledgments.
- Data is often written to multiple nodes before confirming success.
🧩 CAP Theorem vs ACID
- CAP: You can only guarantee 2 of 3 — Consistency, Availability, Partition tolerance.
- ACID is hard to achieve in systems that favor Availability and Partition Tolerance (AP).
So distributed databases often choose:
- ✅ BASE model: Basically Available, Soft state, Eventual consistency
- Instead of strict ACID, unless you’re okay with sacrificing availability (e.g., Spanner, CockroachDB use TrueTime or consensus protocols for global ACID).
✅ Real-World Examples
| System | ACID Support | Notes |
|---|---|---|
| PostgreSQL (single-node) | ✅ Full ACID | Reliable, but not distributed |
| MySQL Group Replication | ⚠️ Partial ACID | Delays for strong consistency |
| Google Spanner | ✅ Global ACID | Uses atomic clocks (TrueTime) |
| CockroachDB | ✅ Serializable isolation | Uses Raft consensus |
| Cassandra, DynamoDB | ❌ Not ACID | Focus on availability (AP) |
🧠 Summary
ACID in distributed systems is achievable, but often at the cost of performance and availability. Systems that implement it usually rely on consensus protocols (like Paxos/Raft), global clocks, or complex coordination logic.