Write-Ahead Log (WAL)
maang.io System Design Series
A write-ahead log enforces one deceptively simple rule: write down what you're about to do, before you do it. That single ordering — log record to durable storage first, data change second — is what lets a database survive a crash without losing or corrupting an acknowledged write. It's the foundation under durability and atomicity, and you'll meet it again inside Cassandra's commit log, RocksDB, and Kafka's partitions.
This deep dive comes in three parts:
- Foundations & Core Concepts — the log-before-data rule, log records, the LSN, and redo vs undo.
- Internals — ARIES three-pass recovery, checkpoints, physiological logging, and group commit, with worked numbers.
- Interview — Staff/Principal Q&A: durability guarantees, recovery reasoning, and the tuning trade-offs.
Write-Ahead Log (WAL) — Part 2: Internals & Recovery
maang.io System Design Series
What is this?
Back to the kitchen ticket rail. In Part 1 we established the rule: write the ticket before you cook. Now we walk into the kitchen after a fire alarm cleared the building mid-service and watch the head chef bring everything back to a correct state. Some dishes were fully served (committed) but the kitchen's memory of them is gone — those must be remade from the tickets. Some dishes were half-cooked when the alarm rang (uncommitted) — those must be scraped. And crucially, the chef doesn't re-read every ticket since the restaurant opened; a periodic "all-caught-up" marker on the rail (a checkpoint) tells them roughly where to start. Getting this recovery exactly right — fast, correct, and idempotent even if the fire alarm rings again during recovery — is what the WAL's internals are built for.
This chapter is the machinery: what a log record actually contains, how the write path really flows through the buffer pool, why fsync is the expensive villain and how group commit tames it, how checkpoints bound recovery time, and finally ARIES — the three-pass recovery algorithm that virtually every serious database implements.
The one-line idea: The WAL is only half the system; the other half is the recovery algorithm that reads it. WAL makes changes durable cheaply; ARIES makes recovery correct and bounded by replaying the log in three disciplined passes — analysis, then redo, then undo — using LSN comparisons to touch each change exactly the right number of times.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson