We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Database Fundamentals
An alternative to ACID for distributed systems: Basically Available, Soft state, Eventually consistent. Trades strong consistency for availability.
In short
BASE is a consistency model for distributed databases that stands for Basically Available, Soft state, and Eventually consistent. Instead of guaranteeing every read sees the latest write right away (as ACID does), a BASE system stays available under failure and lets all copies of the data converge to the same value a short time later.
In short
BASE is a consistency model for distributed databases that stands for Basically Available, Soft state, and Eventually consistent. Instead of guaranteeing every read sees the latest write right away (as ACID does), a BASE system stays available under failure and lets all copies of the data converge to the same value a short time later.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers BASE across a run of lessons, not one page. These 4 alone are about 111 minutes of step-by-step reading, every one with a quiz.
Distributed system consistency model that trades strong consistency for availability.
Find slow queries and optimize database performance. EXPLAIN plans, index analysis, and query rewriting.
How a replica is promoted to primary when a database fails, step by step. Covers RPO vs RTO, split brain, fencing, and the 2018 GitHub outage.
Your database already cached the disk, so what a query cache saves is CPU, and that varies by 430 times between queries.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with BASE Propertiespay once,
yours for life
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.
Amazon DynamoDB
Built on the original Dynamo design; defaults to eventually consistent reads for low latency and high availability, with strongly consistent reads available as an opt-in.
Apache Cassandra
Wide-column store with tunable per-query consistency levels (ONE, QUORUM, ALL) so teams pick the BASE-to-strong balance they need.
Riak
Key-value store modeled closely on the Dynamo paper, using vector clocks and read repair to converge replicas after conflicting writes.
Couchbase / CouchDB
Document databases that accept writes locally and replicate asynchronously, reconciling versions so distributed and offline-first apps stay available.
They sit at opposite ends of a spectrum but are not enemies. ACID guarantees every read is current at the cost of sometimes refusing service; BASE guarantees the system stays available at the cost of brief staleness. Many real systems use both: ACID for money and inventory, BASE for feeds and counters.
No. It means different replicas can briefly disagree, but if writes stop they all converge to the same correct value. You never lose data; you just might read a slightly old version for a short window, typically milliseconds to a couple of seconds.
CAP says that during a network partition you must choose between consistency and availability. BASE is what you get when you choose availability: the system keeps answering and reconciles later. ACID with strong consistency is what you get when you choose consistency and reject requests during the partition.
Often yes, per operation. Systems like Cassandra and DynamoDB let you request quorum or strongly consistent reads when a specific query needs it, while the rest of your traffic stays eventually consistent for speed.
It means the stored data can change on its own over time, without a new client write, because background processes are still replicating and reconciling earlier writes across nodes. The state is not fixed the instant a write is acknowledged.
Database Profiling
Find slow queries and optimize database performance. EXPLAIN plans, index analysis, and query rewriting
Database Failover
How a replica is promoted to primary when a database fails, step by step. Covers RPO vs RTO, split brain, fencing, and the 2018 GitHub outage.
Database Query Caching
Your database already cached the disk, so what a query cache saves is CPU, and that varies by 430 times between queries
Database Connection Pooling
PgBouncer, HikariCP, and why opening a new database connection per request is a recipe for disaster
Database Sharding
Splitting a database across multiple servers, the nuclear option for scaling writes, and the architecture behind Instagram, Uber, and YouTube
ACID
Four guarantees for database transactions: Atomicity (all or nothing), Consistency (valid states only), Isolation (no interference), Durability (changes persist).
CAP Theorem
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
Database
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
SQL
Structured Query Language for managing relational databases. Tables, rows, columns, and powerful joins to query related data.
Sharding
Splitting a database into smaller pieces (shards) distributed across multiple servers. Each shard holds a subset of the data.
This page explains the idea. The "BASE Properties" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the BASE Properties lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about BASE in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
