BASE

Pradeep P
2 days ago
3 min read

Series: Modern System Design · Layer 4 — Data

Layer 4 · Post 12 of 17

← Previous: Fencing Tokens and Leases → Next: Transactional Outbox

Layer 4 — Data · Post 106 of 119

BASE is the slogan for stores that stay up by allowing replicas to disagree for a while.

What you'll learn

What Basically Available, Soft state, and Eventual consistency mean in practice
How BASE relates to ACID and to PACELC — not as opposites in a holy war
When a shopping cart can be BASE and a ledger must not

The idea in one minute

BASE (Pritchett, late 2000s, in the Dynamo era) was a slogan against "every system must be ACID":

Basically Available: the system prefers to answer (AP / PA in PACELC) rather than refuse during partial failure.
Soft state: replicas may be wrong for a while; you do not pretend there is one copy.
Eventual consistency: if writes stop, copies converge (Post 44).

ACID:  one transaction, one truth (on one engine), or it didn't happen
BASE:  stay up; truth is a process (repair, read-repair, CRDTs)

It is a design posture, not a SQL mode you SET. Dynamo, Cassandra, Riak, DNS, and many caches are BASE-shaped. Postgres is ACID-shaped. You can put BASE around ACID (async replicas, search indexes).

Why it matters

Interviews still contrast ACID vs BASE. The grown-up answer is which API. Ledger lines are ACID (or serializable consensus). "Last 10 likes" can be BASE. CAP/PACELC are the failure and latency names; BASE is the 1990s–2000s product name for the AP/EL side.

If you only know ACID, you over-2PC. If you only know BASE, you eventual-consistency a bank.

How it works

Basically available. When a replica is down, remaining nodes still take reads/writes under your quorum settings (W=1, sloppy quorum, hinted handoff). You chose not to wait for the missing copy.

Soft state. Caches, materialized views, and replica lag are the product. TTL, anti-entropy, and "rebuild from the log" are how you live with it. The opposite is "every read is a linearizable query to the leader."

Eventual. Name the merge: last-write-wins, timestamps, vector clocks (Post 110), CRDTs (Post 109). "Eventual" without a merge is "we hope."

BASE does not mean no transactions. Many BASE stores have per-partition or per-key atomicity. Multi-key ACID is what they skipped.

ACID is not "slow BASE." ACID is a contract (Post 40). A fast NVMe Postgres is still ACID. A slow Cassandra cluster is still BASE. Do not use the slogan as a performance claim.

A simple example

Shopping cart in two regions. User adds items on a plane (flaky network). A BASE cart accepts the add on the reachable replica. Later, merge: two "add milk" lines become quantity 2, or LWW drops one — you picked a merge. Checkout then hits an ACID inventory row (or a saga) so you do not sell the same SKU twice. The cart was BASE; the sale was not.

A naive "the whole app is BASE" would eventual-consistency the charge. Don't.

Common mistakes

BASE as "NoSQL." Mongo can majority-ack (CP-ish). Cassandra can QUORUM. The engine is not the slogan; the settings and the API are.

Soft state as an excuse for no backups. Eventual still needs a source of truth or you converge to empty.

Explaining BASE as the letters only. Interviewers want availability during replica loss and convergence, not a crossword.

Using BASE to skip idempotency. Duplicates still happen. Especially under hinted handoff.

How this shows up in real systems

Dynamo paper, Cassandra, Riak, Voldemort: the BASE canon.
S3 / DynamoDB default reads: eventual; strong reads are a different contract.
DNS: the original BASE-looking global database.
Search indexes, feature stores, Redis replicas: BASE views of an ACID (or log) source.

Recap

BASE: stay up, accept temporary disagreement, converge.
Pick it per use case; it is not a personality type for the company.
Next: how to publish events without lying to Kafka — transactional outbox.