Learn the vocabulary of guaranteeing a database change survives a crash before it's applied.
0 / 5 completed
1 / 5
At standup, a dev mentions that a database records every change to an append-only log on durable storage before applying that change to its actual data files. What is this durability mechanism called?
A write-ahead log, or WAL, records every change to an append-only log on durable storage before that change is actually applied to the database's own data files, guaranteeing the change survives a crash even if it hadn't yet been applied to the main data files. Applying a change directly to the data files first, with no separate log, risks losing that change entirely if a crash happens mid-write. This log-first ordering is the foundation of how a database guarantees durability after a commit.
2 / 5
During a design review, the team wants the database to replay its write-ahead log after an unexpected crash, reconstructing any change that hadn't yet been fully applied to the data files. Which capability supports this?
Crash recovery through write-ahead log replay reconstructs any change that hadn't yet been fully applied to the data files by replaying the durable log after an unexpected crash. Assuming a clean restart with no replay risks silently losing a committed change that was logged but not yet applied. This replay mechanism is what lets a database confidently promise that a committed change survives a crash, not just an orderly shutdown.
3 / 5
In a code review, a dev notices the database periodically checkpoints its data files to match the write-ahead log, allowing older log entries to be safely discarded rather than growing the log indefinitely. What does this represent?
Checkpointing periodically syncs the data files to match the write-ahead log, allowing an older log entry to be safely discarded once its change is confirmed to be reflected in the data files. Keeping every log entry forever with no checkpointing would grow the log without bound and slow down crash recovery, since a longer log takes longer to replay. This checkpointing is what keeps a write-ahead log's size and recovery time manageable over the database's lifetime.
4 / 5
An incident report shows recovery after a crash took an unusually long time because checkpointing had been disabled for weeks, leaving an enormous, unbounded write-ahead log that had to be fully replayed. What practice would prevent this?
Running checkpointing on a regular schedule keeps the write-ahead log bounded, since an older entry can be safely discarded once its change is reflected in the data files, which in turn keeps a future crash recovery fast. Disabling checkpointing lets the log grow indefinitely, extending recovery time enormously, exactly as this incident describes. This regular checkpointing is essential to keeping a database's crash-recovery time predictable and fast.
5 / 5
During a PR review, a teammate asks why the database writes to a durable log before applying a change to its actual data files instead of just applying the change directly and skipping the extra log-write step. What is the reasoning?
Applying a change directly to the data files with no durable log risks losing that change entirely if a crash happens mid-write, before the change was ever safely recorded anywhere. Writing to the log first guarantees the change can be recovered and correctly applied even after an unexpected crash. The tradeoff is the extra write the database performs for every single change, which a well-designed WAL implementation keeps fast through sequential, append-only writes.