BASE

BASE is the answer to a question ACID could not solve cheaply: how do you keep a database online and fast when the data lives on dozens or hundreds of machines spread across the world? The acronym breaks into three promises that are deliberately weaker than ACID's.

Basically Available means the system answers every request, even during a partial failure. You might get slightly stale data or a partial result, but you do not get a hard error or a hung connection. Soft state means the data can change over time even without new writes, because the system is still reconciling copies in the background. Eventually consistent means if writes stop, every replica will agree on the same value after some delay, usually milliseconds to a few seconds.

The core trade is right there: ACID buys you correctness on every single read by sometimes refusing service, while BASE buys you uptime and low latency by sometimes serving data that is a beat behind.

A BASE system stores multiple copies of each piece of data on different nodes. When you write, the write is accepted by one or a few nodes and acknowledged immediately, before all replicas have the new value. Background replication then pushes the change to the rest.

Because copies can briefly disagree, the system needs a way to settle conflicts. Common techniques are last-write-wins using timestamps, vector clocks that track causal order, or merge logic where the application reconciles two versions. Amazon's Dynamo paper popularized vector clocks plus client-side conflict resolution for shopping carts.

Many systems expose tunable consistency so you are not locked into one extreme. In Cassandra you choose a consistency level per query: write to ONE node for speed, or require QUORUM (a majority of replicas) to acknowledge before the write counts. When read quorum plus write quorum exceed the replica count, you get strong consistency on that operation while keeping BASE behavior everywhere else.

BASE fits data where a few seconds of staleness costs nothing: social media feeds, view counts, product catalogs, session stores, shopping carts, IoT telemetry, and analytics. These workloads value being always-on and globally fast over being perfectly current.

Avoid BASE where a stale read causes real harm. Bank account balances, inventory at the moment of checkout, seat reservations, and anything with a uniqueness rule usually need ACID transactions and strong consistency. Reading an old balance can let a customer overdraw or double-spend.

The hidden cost of BASE is in your application code. Because the database no longer hides inconsistency, you have to design for it: handle the case where two devices wrote different values, make operations idempotent so retries are safe, and decide what to show a user who reads before replication finishes. The CAP theorem frames the choice plainly: during a network partition you pick availability (BASE) or consistency (ACID), not both.

Picture liking a post on Instagram. You tap the heart and the count jumps instantly because the write was accepted by one nearby replica and acknowledged right away. That is Basically Available and fast.

For the next second or two, a friend in another region might still see the old count, because their replica has not received the update yet. That gap is Soft state. Neither of you sees an error, and the app stays snappy.

Within a couple of seconds the replication finishes and every replica shows the same number. That is Eventual Consistency. Nobody was harmed by the brief disagreement, and Instagram never had to take the feature offline or block your tap waiting for global agreement. A bank ledger would make the opposite choice; a like counter is a textbook fit for BASE.