Acid_base

Chapter 10: ACID vs BASE Models

Understanding Database Consistency Models

10.1 Introduction

When designing distributed systems, understanding consistency models is crucial. The choice between ACID and BASE fundamentally impacts how your application handles data.

    Consistency Models Overview
    ==========================

    +--------------------------------------------------+
    |                                                  |
    |   ACID                 BASE                     |
    |                                                  |
    |   - Strong             - Eventual               |
    |   - Immediate         - Relaxed                |
    |   - Pessimistic       - Optimistic             |
    |                                                  |
    +--------------------------------------------------+

    Used by:               Used by:
    - SQL Databases        - NoSQL Databases
    - Financial systems    - Web-scale systems
    - Transactional apps   - Highly scalable apps

10.2 ACID Model

Understanding ACID

ACID is a set of properties guaranteed by database transactions:

    ACID Properties
    ==============

    +---+------------------+----------------------------------+
    | A | Atomicity        | All operations succeed or none  |
    +---+------------------+----------------------------------+
    | C | Consistency      | Data remains valid after trans. |
    +---+------------------+----------------------------------+
    | I | Isolation        | Concurrent tx appear sequential |
    +---+------------------+----------------------------------+
    | D | Durability       | Committed data survives crashes|
    +---+------------------+----------------------------------+

10.2.1 Atomicity

    Atomicity
    =========

    Transaction: Transfer $100 from Account A to Account B

    Before:
    Account A: $500
    Account B: $200

    Operation 1: Deduct $100 from A
    Operation 2: Add $100 to B

    If Operation 2 fails:
    - Operation 1 is rolled back
    - Both accounts unchanged

    Result: Either BOTH succeed or NEITHER succeeds

10.2.2 Consistency

    Consistency
    ==========

    Rules:
    - Account balance cannot be negative
    - Email must be unique

    Example:
    User tries to set balance = -50

    Before: Balance = $100

    Transaction:
    1. Read balance ($100)
    2. Validate (100 - 50 >= 0) ✓
    3. Write -50 ✗ FAILS

    Result: Transaction rejected, data remains valid

10.2.3 Isolation

    Isolation
    =========

    Two concurrent transactions:

    T1: Read X (currently 100)
    T2: Read X (currently 100)
    T1: Write X = 200
    T2: Write X = 300

    Without Isolation (Lost Update):
    +--------------------------------+
    | Final X = 300 (T1's update lost)|
    +--------------------------------+

    With Isolation (Serialized):
    +--------------------------------+
    | Either T1 then T2: X = 300    |
    | Or T2 then T1: X = 200        |
    +--------------------------------+

10.2.4 Durability

    Durability
    ==========

    After commit:
    +--------------------------------+
    | Transaction confirmed           |
    | Response returned to client   |
    +--------------------------------+
                  |
                  v
    Even if system crashes immediately:
    +--------------------------------+
    | Data is saved                  |
    | Recoverable on restart         |
    +--------------------------------+

    Implementation:
    - Write-ahead logs (WAL)
    - Replication to other nodes
    - Battery-backed write cache

10.3 BASE Model

Understanding BASE

BASE is an alternative model used by distributed systems:

    BASE Properties
    ===============

    +---+------------------------+---------------------------+
    | B | Basically Available   | System guarantees avail. |
    |   |                        | (may return stale data) |
    +---+------------------------+---------------------------+
    | S | Soft State            | State may change over    |
    |   |                        | time (even without       |
    |   |                        | input)                   |
    +---+------------------------+---------------------------+
    | E | Eventual Consistency  | System will become       |
    |   |                        | consistent given no      |
    |   |                        | new inputs               |
    +---+------------------------+---------------------------+

10.3.1 Basically Available

    Basically Available
    ==================

    System responds to requests:
    +----------------------------------+
    |                                  |
    |   Even during failures           |
    |   (Network partitions,           |
    |    node failures)               |
    |                                  |
    |   May return:                   |
    |   - Stale data                  |
    |   - Partial results             |
    |   - Error responses             |
    +----------------------------------+

    Example:
    - 3 of 5 nodes available
    - Respond with available data
    - Don't wait for all nodes

10.3.2 Soft State

    Soft State
    ==========

    System state is "soft" - it can change:

    1. Without user input
    +----------------------------------+
    |  Background sync               |
    |  Replica updates               |
    +----------------------------------+

    2. Over time
    +----------------------------------+
    |  Data may be inconsistent      |
    |  Transiently                   |
    +----------------------------------+

    3. Depends on system history
    +----------------------------------+
    |  Current state depends on      |
    |  past events and timing       |
    +----------------------------------+

10.3.3 Eventual Consistency

    Eventual Consistency
    ====================

    Timeline:
    Time: T0 -> T1 -> T2 -> T3 -> T4
          |    |    |    |    |
          v    v    v    v    v
    Node1: W1       R1   R1   R1
    Node2:    W1    R0   R1   R1
    Node3:    W1       R0   R0   R1

    At T1: Node1 has new value, others have old
    At T2: Two nodes have new value
    At T3: One node still has old value
    At T4: All nodes consistent

    Result: Eventually all nodes agree

10.4 ACID vs BASE Comparison

Side-by-Side Comparison

Aspect	ACID	BASE
Consistency	Strong	Eventual
Availability	May sacrifice	Prioritize
Scale	Limited	Highly scalable
Complexity	Higher	Lower
Latency	Higher	Lower
Use Cases	Financial, transactional	Web, mobile, social

When to Use ACID

Scenario	Example
Financial transactions	Banking, stock trading
Inventory management	E-commerce stock levels
Order processing	Where consistency is critical
Regulatory compliance	Audit trails, legal requirements

When to Use BASE

Scenario	Example
Social media	Likes, comments, feeds
Analytics	Aggregated metrics
User sessions	Shopping carts
Real-time bids	Where speed matters

10.5 Implementing ACID

Database Transaction Example

-- ACID Transaction
START TRANSACTION;

-- Debit from account A
UPDATE accounts
SET balance = balance - 100
WHERE account_id = 'A';

-- Credit to account B
UPDATE accounts
SET balance = balance + 100
WHERE account_id = 'B';

-- Record transaction
INSERT INTO transactions
VALUES (1, 'A', 'B', 100);

COMMIT;
-- If any step fails: ROLLBACK

Two-Phase Commit (Distributed ACID)

    Two-Phase Commit
    ===============

    Phase 1: Prepare
    +-------------+      +-------------+
    | Coordinator| ---> | Participant |
    |             |      |   Node 1    |
    +-------------+      +-------------+
              | Prepare?
              | <--- OK
              |
              v
    Phase 2: Commit
    +-------------+      +-------------+
    | Coordinator| ---> | Participant |
    |             |      |   Node 1    |
    +-------------+      +-------------+
              | Commit
              | ---> OK
              |
              v
    Done!

10.6 Implementing BASE

Conflict-Free Replicated Data Types (CRDTs)

    CRDT Example: Counter
    ====================

    G-Counter (Grow-only Counter):

    Node A: [1, 0, 0]  (increment = 1)
    Node B: [1, 1, 0]  (increment = 1)
    Node C: [1, 1, 1]  (increment = 1)

    Merge (element-wise max):
    [max(1,1,1), max(0,1,1), max(0,0,1)] = [1,1,1]

    Total: 1+1+1 = 3

    Always consistent, no conflicts!

Version Vectors

    Version Vectors
    ==============

    Track causality between nodes:

    Node A: {A: 2, B: 1}  (2 updates from A, 1 from B)
    Node B: {A: 2, B: 1}

    If Node A gets: {A: 3, B: 1}
    - A is ahead, can fast-forward

    If Node A gets: {A: 2, B: 2}
    - Both have different updates, need merge

10.7 Hybrid Approaches

Some Systems Support Both

Database	Model	Notes
PostgreSQL	ACID	Can tune isolation levels
MongoDB	BASE + ACID	Tunable consistency
DynamoDB	BASE	Can choose strong/evenutal
CockroachDB	ACID	Globally distributed SQL
Cassandra	BASE	Can use lightweight transactions

Tuning Consistency in DynamoDB

    DynamoDB Consistency
    ====================

    Read Consistency Options:

    Eventually Consistent (default):
    - Lower latency
    - May return stale data
    - 2 of 3 nodes must respond

    Strongly Consistent:
    - Higher latency
    - Always current data
    - All 3 nodes must respond

    Trade-off:
    +------------------------+----------------+
    | Eventually Consistent | Strong Consistent|
    +------------------------+----------------+
    | ~10ms read            | ~30ms read     |
    | Free capacity: 2x     | Full capacity  |
    +------------------------+----------------+

10.8 Making the Choice

Decision Framework

    Choose ACID when:
    ================

    - Data integrity is critical
    - Transactions are required
    - Regulatory compliance
    - Write patterns are moderate
    - Can handle vertical scaling

    Choose BASE when:
    ================

    - Scale is priority
    - Eventual consistency acceptable
    - High write throughput
    - Geographic distribution
    - User-facing (speed matters)

Summary

Key concepts:

ACID = Strong guarantees - Consistency, but potentially lower availability
BASE = Eventual consistency - Higher availability, may be stale
Choose based on requirements - Not a one-size-fits-all
Modern systems often hybrid - Tunable consistency
CRDTs enable BASE - Conflict-free data types
Isolation levels matter - ACID can be tuned

Next: Chapter 11: Monolithic Architecture