ACID and BASE are two ways to describe how database systems handle reliability, consistency, and performance. Students need this cheat sheet because modern applications often choose between strict correctness and high scalability. Understanding these properties helps explain why banks, shopping carts, social networks, and distributed apps use different database designs.
ACID stands for Atomicity, Consistency, Isolation, and Durability, which support safe transactions in traditional relational databases. BASE stands for Basically Available, Soft state, and Eventual consistency, which supports large distributed systems that must stay responsive. The CAP theorem explains that during a network partition, a distributed system must choose between consistency and availability.
Key Facts
- ACID = Atomicity + Consistency + Isolation + Durability.
- Atomicity means a transaction is all-or-nothing, so if one step fails, the entire transaction is rolled back.
- Consistency means every committed transaction moves the database from one valid state to another valid state according to rules and constraints.
- Isolation means concurrent transactions should not interfere with each other, as if they ran one at a time.
- Durability means once a transaction commits, its data remains saved even after a crash or power failure.
- BASE = Basically Available + Soft state + Eventual consistency.
- Eventual consistency means replicas may temporarily disagree, but they should converge to the same value if no new updates occur.
- CAP theorem = Consistency, Availability, and Partition tolerance, but during a partition a distributed system can fully guarantee only two of the three.
Vocabulary
- Transaction
- A transaction is a sequence of database operations treated as one logical unit of work.
- ACID
- ACID is a set of properties that make database transactions reliable and strongly consistent.
- BASE
- BASE is a set of properties that favors availability and scalability while allowing temporary inconsistency.
- Consistency
- Consistency means data follows required rules, constraints, or replica agreement depending on the database context.
- Availability
- Availability means every request receives a response, even if the response may not contain the most recent data.
- Partition tolerance
- Partition tolerance means a distributed system continues operating even when network failures separate nodes.
Common Mistakes to Avoid
- Confusing ACID consistency with CAP consistency is wrong because ACID consistency means valid database states, while CAP consistency means all clients see the same latest data.
- Thinking BASE means no consistency is wrong because BASE usually means eventual consistency, where replicas are expected to agree later.
- Assuming every database is either only ACID or only BASE is wrong because many modern systems support configurable consistency and hybrid behavior.
- Ignoring network partitions is wrong because distributed systems must be designed for communication failures between nodes.
- Choosing availability for every application is wrong because systems such as banking, ticket sales, and inventory may require strict correctness over fast responses.
Practice Questions
- 1 A bank transfer subtracts 50 to Account B. Which ACID property is violated if the subtraction happens but the addition fails?
- 2 A distributed database has 5 replicas. After an update, 2 replicas show the new value and 3 still show the old value for a short time. Which BASE concept does this illustrate?
- 3 During a network partition, an online service chooses to keep answering user requests even if some users may see stale data. In CAP terms, which property is favored over strict consistency?
- 4 Explain why a social media like counter might accept eventual consistency, but a payment processing system usually needs stronger ACID-style guarantees.
Understanding ACID vs BASE Database Properties
A transaction is usually implemented as a carefully recorded sequence of changes. Consider moving money between two accounts. The system first records enough information to undo the work if a later step fails.
Many databases use a write ahead log, which saves this record to stable storage before reporting success. After a crash, recovery software reads the log. It completes changes that were safely committed or removes incomplete changes.
This is why a committed payment can survive a power cut. The cost is extra disk work and coordination, which can make each write slower than a simple update.
Isolation becomes important when many users act at nearly the same moment. Without protection, two shoppers could both see one remaining ticket and both try to buy it. Databases handle this with locks, version numbers, or multiversion concurrency control.
A lock can make one transaction wait. Versioning can let readers use an older stable copy while a writer prepares a new one. Different isolation levels permit different amounts of overlap.
Lower levels may improve speed but can expose stale reads or lost updates. Students should separate database consistency from the consistency in CAP.
The first means following data rules. The second means every replica returns the same latest value.
Distributed databases store copies of data on several machines, often in different places. Copies improve response time and help a service continue after one machine fails. They create a hard problem when machines cannot communicate because a cable, router, or data center has failed.
A system that favors CAP consistency may reject or delay a request until it can verify the latest value. A system that favors availability may accept the request on one side of the split and synchronize later.
Eventual convergence needs rules for conflicts. A system might use timestamps, version vectors, a chosen primary copy, or application rules such as merging two sets of likes.
The best choice depends on the harm caused by an incorrect temporary answer. A bank transfer, exam score, or seat reservation normally needs strict checks before confirmation. A social media feed can tolerate showing an old post count for a short time.
Many real systems combine both approaches. An online shop may use transactions for orders and stock, while using eventually consistent copies for search results and recommendations. When studying examples, identify the data being protected, the failure being considered, and what users are allowed to see while replicas disagree.
Tradeoffs are not labels for good or bad databases. They are design decisions based on risk, scale, and user expectations.