Write-Ahead Log
The WAL decouples data-page writes from commit time and enables recovery.
- Write aheadRecovery information becomes durable before the changed data page.
- CommitThe database acknowledges a transaction according to its configured durability rule.
- ReplayAfter a crash, the database reconstructs committed changes from the log.
Context
Why this is important
Architecture decisions depend on which failure is survived after which acknowledgement.
This profile explains the database mechanism. The separate payment database is hypothetical; the current shop uses seven modules and one shared database.
Distinguish WAL guarantees
The current shop runs Catalog, Cart, Order, Payment, Inventory, Shipping, and Invoice as seven modules in a modular monolith with one shared database. For a hypothetical separate payment database, the server confirms an authorization only after the required WAL records are durable. The team terminates the process after commit but before the data page write and verifies recovery after restart. Only an additionally configured synchronous replication rule would include acknowledgement by a second node in the commit guarantee.
This is how you read the picture
- Write ahead WAL flush before page flush
- Commit Name local or synchronous acknowledgement
- Replay Test failure point and outcome reproducibly
| Comparison | Mechanism | Proves | Does not yet prove |
|---|---|---|---|
| Local WAL commit | Log record durable on the acknowledging node | Local crash recovery under the configuration | A copy on a second node |
| Synchronous replication | Required replica acknowledgement before commit response | Survival of the agreed node failure | Business processing by a consumer |
| Logical decoding | Changes in a consumable form | Positioned change stream | Exactly-once business effect |
Benefits & limitations
Helps if:
- A WAL fits as a database mechanism when committed transactions must recover after a process or machine crash.
- WAL-based replication fits when replicas must follow the same change history at storage or logical level.
- Logical decoding fits when selected committed changes must be consumed outside the database.
Boundaries
- The commit guarantee depends on flush, storage, and synchronization configuration; a successful API call alone does not describe it.
- A local WAL commit guarantees neither replica acknowledgement nor business processing in a downstream system.
- Archiving and replication positions can retain WAL segments for a long time. The team needs thresholds for lag, storage, and recovery time.
In practice
- Trace a committed payment transaction through durable log records to the later data-page write. Identify which information recovery requires.
- Simulate a database restart after commit but before the data page is written. Follow how WAL restores the committed state.
- Assess the retention and archiving required by the chosen WAL setup. Separate local crash recovery from a replication guarantee to other nodes.
Read the detailed explanation
At commit, the database ensures that the required WAL records are durable. Data pages may be written later; after a crash, recovery replays logged changes and discards incomplete work.
WAL ordering and database transactions belong together, but they do not form a ready-made business event contract. Physical replication transfers storage changes; logical decoding translates selected changes into a consumable form.
Transactions define the atomic business change inside the database. Replication adds copies and availability rules. A WAL commit proves local durability according to the specific database configuration.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What must be durable before the data page?
View the solution with justification
The WAL records required for recovery.
ApplyingTransferred to a new situation
Which test demonstrates crash recovery in the shop scenario?
View the solution with justification
A termination after commit and before page flush, followed by evidence that the acknowledged authorization is recovered.
EvaluateWeighing an alternative
When may a team claim replica durability?
View the solution with justification
When the concrete synchronous acknowledgement rule, participating node, and tested failure are named.
Explore further
These building blocks continue the thoughts of this page.