ACID vs BASE Database Consistency Models

Modern distributed systems face a fundamental choice between strong consistency (ACID) and eventual consistency (BASE). This article explores both models, their tradeoffs, and implementation considerations.

ACID Properties

ACID (Atomicity, Consistency, Isolation, Durability) prioritizes data consistency and reliability.

graph LR
    A[Transaction] --> B[Atomicity]
    A --> C[Consistency]
    A --> D[Isolation]
    A --> E[Durability]
    B --> F[All or Nothing]
    C --> G[Valid State]
    D --> H[Concurrent Safety]
    E --> I[Permanent]
    style A fill:#f9f,stroke:#333
    style F fill:#ddf,stroke:#333
    style G fill:#ddf,stroke:#333
    style H fill:#ddf,stroke:#333
    style I fill:#ddf,stroke:#333

The diagram illustrates the four pillars of ACID transactions:

  1. Atomicity ensures operations are “all or nothing”
  2. Consistency maintains valid database states
  3. Isolation provides concurrent transaction safety
  4. Durability guarantees permanent data storage

Each property leads to a specific guarantee, shown by the terminal nodes.

Implementation Example

sequenceDiagram
    participant C as Client
    participant N1 as Node 1
    participant N2 as Node 2
    participant N3 as Node 3
    
    C->>N1: Begin Transaction
    N1->>N2: Lock Data
    N1->>N3: Lock Data
    N2-->>N1: Locked
    N3-->>N1: Locked
    N1->>N2: Write Data
    N1->>N3: Write Data
    N2-->>N1: Success
    N3-->>N1: Success
    N1->>N2: Commit
    N1->>N3: Commit
    N1->>C: Transaction Complete

This sequence diagram shows a distributed ACID transaction:

  1. Client initiates transaction with Node 1
  2. Node 1 acquires locks on Node 2 and 3
  3. After confirmation, data is written to all nodes
  4. Two-phase commit ensures consistency
  5. Client receives completion confirmation only after all nodes commit

BASE Properties

BASE (Basically Available, Soft state, Eventually consistent) prioritizes availability and partition tolerance.

graph LR
    A[BASE Model] --> B[Basic Availability]
    A --> C[Soft State]
    A --> D[Eventual Consistency]
    B --> E[System Remains Available]
    C --> F[State May Change]
    D --> G[Consistency Over Time]
    style A fill:#f9f,stroke:#333
    style E fill:#ddf,stroke:#333
    style F fill:#ddf,stroke:#333
    style G fill:#ddf,stroke:#333

Diagram shows BASE characteristics:

  1. Basic Availability ensures system operation
  2. Soft State allows temporary inconsistencies
  3. Eventual Consistency guarantees convergence over time

Each property leads to a specific system behavior shown in the terminal nodes.

Implementation Example

graph LR
    A[Client] --> B[Node 1]
    A --> C[Node 2]
    B --> D[(Datastore Local)]
    C --> E[(Datastore Local)]
    D -.-> F[Eventual Consistency]
    E -.-> F
    style F fill:#ccf,stroke:#333,stroke-width:2px

This diagram illustrates a BASE system:

  1. Clients can write to any node
  2. Each node has a local datastore
  3. Dotted lines show eventual consistency mechanism
  4. Data synchronizes across nodes over time

Implementation Patterns

Two-Phase Commit (2PC)

sequenceDiagram
    participant C as Coordinator
    participant P1 as Participant 1
    participant P2 as Participant 2
    
    C->>P1: Prepare
    C->>P2: Prepare
    P1-->>C: Ready
    P2-->>C: Ready
    C->>P1: Commit
    C->>P2: Commit

Diagram shows two-phase commit protocol:

  1. Prepare phase: Coordinator asks participants to prepare
  2. Commit phase: After all ready, coordinator commits
  3. Ensures atomic transaction across distributed system

Three-Phase Commit (3PC)

sequenceDiagram
    participant C as Coordinator
    participant P1 as Participant 1
    participant P2 as Participant 2
    
    C->>P1: CanCommit?
    C->>P2: CanCommit?
    P1-->>C: Yes
    P2-->>C: Yes
    C->>P1: PreCommit
    C->>P2: PreCommit
    P1-->>C: Ready
    P2-->>C: Ready
    C->>P1: DoCommit
    C->>P2: DoCommit

Diagram shows three-phase commit:

  1. CanCommit: Initial feasibility check
  2. PreCommit: Preparation phase
  3. DoCommit: Final commit phase Adds timeout safety over 2PC

Event Sourcing Pattern

graph LR
    A[Event] --> B[Event Store]
    B --> C[Projections]
    C --> D[Query Model]
    C --> E[Analytics]
    style B fill:#f9f,stroke:#333

Diagram shows event-based architecture:

  1. Events are primary source of truth
  2. Event Store maintains complete history
  3. Projections create different views
  4. Supports both querying and analytics

CQRS Pattern

graph LR
    A[Commands] --> B[Write Model]
    C[Queries] --> D[Read Model]
    B --> E[Event Bus]
    E --> D
    style E fill:#f9f,stroke:#333

Diagram shows Command Query Responsibility Segregation:

  1. Separates write and read models
  2. Commands handle data modifications
  3. Queries access read-optimized views
  4. Event bus synchronizes models

Hybrid Architecture

graph TB
    A[Application] --> B[Critical Operations]
    A --> C[Non-Critical Operations]
    B --> D[(ACID Database)]
    C --> E[(BASE Storage)]
    D -.-> F[Sync Service]
    E -.-> F
    style F fill:#f9f,stroke:#333,stroke-width:2px

Diagram shows practical combination of ACID and BASE:

  1. Critical operations use ACID database
  2. Non-critical operations use BASE storage
  3. Sync service maintains consistency
  4. Balances reliability and scalability