A refund moves ₹500 from Tiffin's balance into Priya's wallet. Inside Postgres, that's two rows on two different 8 KB pages: Tiffin's balance goes down, Priya's goes up. The database writes the first page to disk. Then the power goes out before it writes the second.
When the server comes back, ₹500 has vanished. Or, if the pages were written in the other order, ₹500 has appeared from nowhere. The transaction promised all-or-nothing, and the disk delivered half.
Every serious database solves this the same way: before changing any data page on disk, it first writes a note saying what it's about to do, to an append-only file called the write-ahead log (WAL).
Why not just write the pages carefully?
Three facts make direct page writes unsafe:
- A transaction touches many pages, often in different files. Disks can't update several places atomically.
- Databases cache pages in memory and write them back later, in whatever order is convenient. Writing every changed page at commit would be slow: lots of random I/O.
- A single page write can be torn. An 8 KB database page is often written as several smaller disk sectors. A crash halfway leaves a page that's half old, half new.
The WAL turns many scattered random writes into one sequential append, and gives the database a record to repair from.