BASE Properties

framework · computer science · organizing-schema

Basically Available, Soft state, Eventual consistency — pragmatic alternative to ACID.

BASE is the deliberate counterpoint to ACID for distributed systems, articulated by Dan Pritchett in his 2008 ACM Queue article 'BASE: An ACID Alternative' to characterize the consistency model used by large-scale internet systems including those at eBay where Pritchett was an architect. The acronym (deliberately playing on chemistry — bases are weaker than acids) stands for Basically Available (the system responds to every request, possibly with stale or partial data), Soft state (system state may change without input as eventual consistency propagates), and Eventually consistent (the system will become consistent over time, given the absence of new updates). BASE captures the architectural compromises made when AP-side CAP trade-offs are necessary at internet scale, and is associated with NoSQL databases, caching layers, and eventually-consistent replication. The framework provides vocabulary for the design choices but does not, unlike ACID, specify formal semantic guarantees — applications using BASE systems must reason carefully about which inconsistencies are tolerable.

Originators

Dan Pritchett (codification); Eric Brewer (foundational thinking through CAP work) high

Year / Decade

2008 (Pritchett ACM Queue article); 1990s-2000s industry practice precursor high

Primary sources

Pritchett, D. (2008). 'BASE: An ACID Alternative', ACM Queue high

Core components

Basically Available (responds to every request, possibly with stale data)
Soft state (state may change without input as consistency propagates)
Eventually consistent (will reach consistency given quiet time)
Trade-off vs ACID strict guarantees
Application-level reasoning about acceptable inconsistencies
Connection to AP-side CAP choices
Common in NoSQL databases, caching, eventually-consistent replication

Primary use case

Internet-scale distributed systems where availability matters more than strict consistency; e-commerce, social media, content delivery, caching layers; NoSQL database design (Cassandra, Riak, DynamoDB at certain configurations); architectural framing for designing systems on the AP side of CAP.

Common criticisms

Less precise than ACID's formal guarantees — 'eventually consistent' permits a wide range of behaviors that applications must reason about individually
BASE-labeled systems vary substantially in actual consistency semantics
can become an excuse for not thinking carefully about correctness ('we're just eventually consistent')
the chemistry-pun acronym is sometimes more memorable than analytically useful
many real systems are neither pure ACID nor pure BASE but mixed, with BASE-style framing potentially obscuring needed nuance
doesn't address what to do when eventual consistency takes too long for application requirements.

Lineage

Siblings: ACID Properties, CAP Theorem