There was a loud little eatery down by the harbor, busy enough that on a good night eight pans smoked on the stove at once. The woman who ran the pass was named Ah-Shuang, and she kept one iron rule no one in the shop dared break: before any dish touches a pan, it goes into the book first.

It was a heavy ledger, chained to the wooden counter at the pass so no one could carry it off. When a guest ordered, Ah-Shuang did not shout and did not move — she dipped her brush and wrote it out, stroke by stroke, on the next empty line: which table, which dish, how well done. Only when the ink had dried did she turn and call it to the stove. The rule sounded foolish — guests grumbling while she wrote — but she never bent it: “If the ink isn’t dry, the dish doesn’t count.” And when a plate went out and the guest had truly taken it, she came back and added a small mark — done — beside that line.

One night late that autumn a gust tore through and snuffed every oil lamp at once. Sparks still hissed on the stove; everyone scrambled out into the back yard. When the wind passed and the lamps were lit again, the kitchen was chaos: half-cooked fish, scallions cut halfway, no one able to recall which dishes had even been underway — except the book. Ah-Shuang opened it, read down from the last done mark, and remade each line in order: this one delivered, skip it; this one not, finish it. Not a dish was lost, and not a dish was sent to a guest twice. A calamity, untangled by a single ledger.

And because she only ever added lines and never scratched anything out, the book grew thicker and thicker. So each night at closing, once every dish from the evening was confirmed finished, she drew a clean line across the page and started fresh on a new one — and so the ledger never swelled to a thousand unturnable pages.

— By now you’ve probably recognized it: this “ink before the pan” ledger is the write-ahead log (WAL) of databases and etcd.

What it is: before actually modifying the data, you first append, in order, a record of what you intend to do into a log that only grows and is never rewritten, and you make sure it has reached stable storage (fsync). Only once that is done is the operation committed. The real data structures can be updated at leisure; even if the power fails this instant, on restart you simply replay the log to recover the state to a consistent point just before the crash.

Why it matters: a disk write can be interrupted at any moment by a power cut or a crash. If you mutate your data and merely hope nothing goes wrong, a crash leaves you with a pile of half-applied wreckage. The WAL trades one simple ordering guarantee for durability and crash recovery — record the intent, then change the data; on restart, redo from the log. etcd — the heart of every Kubernetes/OpenShift cluster — relies on exactly this to promise that acknowledged writes survive a power loss.

Metaphor map:

• The chained ledger → the write-ahead log itself
• The iron rule, ink before the pan → the write-ahead rule: persist the intent to the log before mutating data
• Writing only the next empty line, never scratching out → sequential, append-only writes
• Counting only once the ink is dry → fsync / durability: an op is committed once its record is on stable storage
• The gust snuffing the lamps → a crash / power loss
• Remaking from the last done mark down → replay (redo) of the log on recovery
• The done mark → a checkpoint
• Drawing a line, a fresh page each night → truncating / compacting the log after a checkpoint to bound its size
• No dish sent out twice → the idempotency of replay