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 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now understand the WAL from the log-before-data rule down to ARIES's three passes. This chapter turns that into interview points and design instincts. Here's the reframe that makes WAL punch above its weight in an interview: the log isn't just a recovery tool — it's a stream. Once you see that the ordered, durable sequence of every change is itself the most valuable object in the system, you unlock replication, change data capture, event sourcing, and Kafka — and you can talk about them as one idea instead of four. That single insight is what separates a candidate who "knows what a WAL is" from one interviewers tag as Staff.
We'll do two things: see where the WAL shows up in real designs (with diagrams), then run a mock interview — each question as what they're really asking → model answer → the senior line. We keep the kitchen ticket rail with us: the tickets aren't just for recovering after a fire — a second cook can read the same rail to make a duplicate plate (a replica), and the rail is a perfect history of everything the kitchen ever did (an event log).
The one-line idea: interviewers use WAL to test whether you see that an ordered, durable log of changes is a reusable primitive — the same object serves durability, replication, and CDC — and whether you can reason honestly about fsync cost, recovery time, and replication lag.
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