Write-Ahead Logs on Object Storage: The MVS Write Path

A write-ahead log is the oldest trick in durable storage: before you change anything, you append what you are about to do to a log, and you do not tell the caller you succeeded until that append lands. Recovery then means replaying the log.

Putting that log on object storage changes what it can be. A local log is a durability mechanism for one machine. A log written to S3 or GCS as a sequence of immutable objects is a shared artifact, and anything that can list a bucket can read it.

MVS writes land in a write-ahead log, and the acknowledgement returns there. That is the beat most people get wrong. The ack does not wait for indexing, so write latency is not coupled to how expensive the index is to update.

Sealed segments ship to object storage as sequenced objects under wal/{namespace}/{shard}/{sequence}.wal. The sequence number is doing real work: a monotonic filename is its own conflict detector, so ordering inside a shard is a property of the naming rather than of a coordinator.

Snapshots compact the chain, and a garbage-collection gate decides what may be deleted. A segment is removed only once its writes are provably inside a committed snapshot. The interesting part is what happens when that proof is unavailable: the gate holds the segment rather than assuming, so a stuck snapshot frontier costs disk instead of data.

Three readers share the chain. Recovery replays shipped segments on top of the last snapshot. Replicas tail it to stay in sync. Change data capture reads the same objects as an event feed. None of them need a private channel to the writer, because the log is the interface.

One thing the diagram marks as planned rather than shipped: a leader fence on the append. Today the segment writes are unconditional, which means a deposed writer that has not yet learned it was deposed could in principle overwrite a sequence the real leader wrote. Conditional, create-only writes close that, and the diagram draws it dashed until they do.