ACID vs BASE — Deep Dive

Level: Intermediate
Pre-reading: 01 · Architectural Foundations · 01.03 · CAP Theorem

Two Models of Data Consistency

Distributed systems force a choice between two consistency models. ACID prioritizes correctness and strong guarantees. BASE prioritizes availability and performance, accepting eventual consistency.

ACID — The Traditional Model

ACID transactions guarantee four properties:

Atomicity — All or Nothing

A transaction either completes entirely or has no effect. If any part fails, all changes are rolled back.

sequenceDiagram
    participant App
    participant DB
    App->>DB: BEGIN TRANSACTION
    App->>DB: UPDATE accounts SET balance = balance - 100 WHERE id = 1
    App->>DB: UPDATE accounts SET balance = balance + 100 WHERE id = 2
    Note over DB: Power failure here
    DB->>DB: ROLLBACK (both updates undone)

Consistency — Valid State Transitions

The database moves from one valid state to another. Constraints (foreign keys, check constraints, triggers) are enforced. Invariants are preserved.

Isolation — Concurrent Transactions Don't Interfere

Transactions execute as if they were serial, even when running concurrently.

sequenceDiagram
    participant T1 as Transaction 1
    participant DB
    participant T2 as Transaction 2
    T1->>DB: SELECT balance WHERE id=1 (returns 100)
    T2->>DB: UPDATE balance = 50 WHERE id=1
    T2->>DB: COMMIT
    T1->>DB: SELECT balance WHERE id=1
    Note over T1,DB: Non-repeatable read: 50 ≠ 100

Durability — Committed Data Survives Failures

Once a transaction commits, its changes persist even if the system crashes immediately after.

ACID Implementation Techniques

Two-Phase Locking (2PL)

Guarantees serializability but can cause deadlocks.

Multi-Version Concurrency Control (MVCC)

Instead of locking, each transaction sees a snapshot of the database at a point in time. Writers create new versions; readers see old versions.

graph LR
    subgraph Row Versions
        V1[Version 1 - created T1]
        V2[Version 2 - created T5]
        V3[Version 3 - created T10]
    end
    T3[Transaction 3] -.->|Sees| V1
    T7[Transaction 7] -.->|Sees| V2
    T12[Transaction 12] -.->|Sees| V3

BASE — The Distributed Model

BASE is the alternative for systems where ACID's guarantees are too expensive:

Basically Available

The system guarantees availability, even during partial failures. Some requests may get degraded responses, but the system doesn't go offline.

Soft State

The system's state may change over time, even without input, due to eventual consistency. Data may be temporarily inconsistent between replicas.

Eventually Consistent

If no new updates are made, all replicas will eventually converge to the same value. The "eventually" may be milliseconds or seconds.

sequenceDiagram
    participant Client
    participant Node1
    participant Node2
    participant Node3
    Client->>Node1: Write X=5
    Node1->>Node1: X=5
    Node1-->>Node2: Async replicate
    Node1-->>Node3: Async replicate
    Note over Node1,Node3: Brief inconsistency window
    Node2->>Node2: X=5
    Node3->>Node3: X=5
    Note over Node1,Node3: Eventually consistent

Eventual Consistency — Deeper Look

Types of Eventual Consistency

The Consistency Window

The time between when a write occurs and when all replicas reflect it.

Comparing ACID and BASE

When to Choose ACID

When to Choose BASE

Distributed Transactions — ACID Across Services

When ACID guarantees are needed across multiple services:

Two-Phase Commit (2PC)

sequenceDiagram
    participant C as Coordinator
    participant P1 as Participant 1
    participant P2 as Participant 2
    Note over C,P2: Phase 1 - Prepare
    C->>P1: Prepare
    C->>P2: Prepare
    P1->>C: Vote YES
    P2->>C: Vote YES
    Note over C,P2: Phase 2 - Commit
    C->>P1: Commit
    C->>P2: Commit
    P1->>C: ACK
    P2->>C: ACK

Saga Pattern — BASE for Cross-Service Transactions

Each step is a local ACID transaction. On failure, execute compensating transactions to undo previous steps.

→ Deep Dive: Saga Pattern for choreography vs orchestration, compensating transactions

Hybrid Approaches

Strong Consistency for Writes, Eventual for Reads

graph LR
    W[Write] --> P[(Primary - Strong)]
    P -->|Async| R1[(Read Replica)]
    P -->|Async| R2[(Read Replica)]
    RD[Read] --> R1
    RD --> R2

Consistency Per Operation

Many databases allow tuning consistency per query:

-- DynamoDB: strongly consistent read
aws dynamodb get-item --consistent-read

-- Cassandra: quorum consistency
SELECT * FROM orders WHERE id = 123 CONSISTENCY QUORUM;

Application-Level Consistency Patterns

When the database doesn't guarantee consistency, the application must: