Write-Ahead Log (WAL)

// WAL operation sequence
//
// 1. Client: INSERT INTO orders VALUES (...)
// 2. DB appends to WAL: "INSERT order-123, {data...}" → fsync to disk ✅
// 3. DB updates in-memory page (B-Tree leaf)
// 4. Client receives "commit OK" (durable — in WAL)
// 5. Background: dirty pages flushed to disk (checkpoint)
//
// Crash after step 2, before step 5:
// → Restart: replay WAL from last checkpoint → data recovered ✅
//
// Crash before step 2:
// → Transaction lost (not committed) → correct behaviour ✅

// PostgreSQL WAL
// Location: pg_wal/ directory
// Segment files: 16 MB each (default)
// WAL level:
//   minimal    — crash recovery only
//   replica    — crash recovery + replication
//   logical    — + logical decoding (CDC)

// WAL performance: sequential writes are 100x faster than random
// HDD: sequential write ~200 MB/s vs random write ~2 MB/s
// SSD: sequential write ~3 GB/s vs random write ~500 MB/s

// Kafka: the entire system IS a WAL
// Topics are append-only logs split into partitions
// Producers append records; consumers read at their own pace
// Records retained for configurable period (not deleted on read)
// Replication: WAL is replicated to follower brokers

// Raft consensus: replicated WAL
// Leader appends command to local log
// Leader replicates log entry to followers
// Once majority ACK → entry is committed
// All nodes apply committed entries to state machine
//
// Log: [1: set x=1] [2: set y=2] [3: del x] [4: set z=3]
//       committed     committed   committed   uncommitted

// Event sourcing: event store is a WAL
// Every state change is an append-only event
// Current state = replay(events)
// Snapshots = checkpoints (avoid replaying entire history)