ACID vs BASE

ACID (Atomicity, Consistency, Isolation, Durability) names the strong guarantees of traditional transactional databases, while BASE (Basically Available, Soft state, Eventual consistency) names the relaxed model many distributed stores adopt to stay available at scale. They mark opposite ends of a spectrum between correctness and availability.

ACID describes four properties of a transaction:

• Atomicity - a transaction fully commits or fully rolls back, never half-applied.
• Consistency - a transaction moves the database from one valid state to another, preserving declared constraints.
• Isolation - concurrent transactions do not observe each other's partial work.
• Durability - once committed, data survives crashes and power loss.

BASE relaxes those guarantees to prioritize availability:

• Basically Available - the system stays responsive even under partial failure.
• Soft state - replica state may be in flux and is not guaranteed identical everywhere at a given instant.
• Eventual consistency - replicas converge to the same value once writes stop.

Enforcing ACID guarantees across multiple nodes is exactly what Distributed Transactions address, and the precise meaning of "eventual" versus stronger guarantees is defined by Consistency Models.

ACID makes application logic simple because the database guarantees correctness, but coordination (locks, consensus) limits throughput and cross-node scale. BASE scales and stays available under partitions but pushes conflict handling and "read-your-writes" concerns into the application. Most real systems are hybrids: an ACID system of record for critical entities alongside BASE stores for high-volume, tolerant data.

• Do not treat this as global; pick per data type. Say "the wallet balance is ACID, the activity feed is BASE" to show judgment.
• Note that some modern databases offer tunable consistency, so the line is a dial, not a binary switch.