Atomic Publication

Atomic publication means making a result visible as one complete version within a defined boundary. Readers following that publication mechanism see an accepted old or new version rather than a mixture from an unfinished update. Here the term names a design property, not a particular product feature.

Build, validate, then expose

Suppose a sales dataset has three files. Overwriting them one by one allows a reader to combine yesterday's first file with today's other files. Instead, build all three under a new version, validate them, then switch the reference that readers use.

The word switch is carrying the weight, so it is worth saying what it has to be: a single update to one thing, which either takes effect or does not. There is no way to make several independent updates atomic by ordering them carefully — replacing file A, then B, then C as separate object writes has no atomic version, whatever the store. What makes the pattern work is indirection: readers consult one pointer, and publishing means moving that pointer from the old version to the new one. Apache Iceberg’s specification describes exactly this shape — each change produces new metadata that replaces the old with an atomic swap, and readers resolve one committed snapshot rather than listing a directory. A manifest file, a table pointer in a catalog, or a symlink are the same idea at different levels of sophistication.

Some object stores with a hierarchical namespace do offer an atomic rename of a folder path, which moves the objects under it together. That is a rename, not a replacement: where the destination already exists the semantics differ, and moving the old folder aside and the new one in is two operations, not one.

So using a folder rename to replace a published version needs the destination-path rules, the reader’s path, and retention checked first. Even then it does not make arbitrary changes to several objects, or a transaction across several tables, atomic.

This also puts a requirement on the reader, which is the half that gets forgotten. A reader that resolves the pointer once and then reads every file that version names is safe; one that re-resolves it between files, or that lists the directory to find files, can still mix versions no matter how carefully the publisher switched. The storage and reference mechanism must actually support the required atomic change, and the reading convention has to be the one the mechanism assumes.

Database transactions provide another approach where the relevant writes belong to one supported transaction. PostgreSQL's transaction introduction explains all-or-nothing effects and the visibility of committed updates.

Name the boundary of the promise

An atomic switch of one reference does not automatically update a separate search index, external cache, and dashboard together. Readers must resolve a consistent version and retain access to its files for the required reading period. Existing readers may legitimately finish using the old version.

Atomicity does not prove completeness or business correctness. A perfectly atomic publication can expose a completely wrong total. Validate the candidate before publication — data quality assertions placed between the build and the switch are what make the boundary useful, because a failed assertion then leaves the previous good version in place — and define recovery when validation or the switch fails. Rebuilding a historical range is the same problem at a different scale: see data backfill.

References

• Google Cloud Storage, Hierarchical namespace overview (atomic folder rename)
• Google Cloud Storage, Rename and move folders
• PostgreSQL: Transactions
• Apache Iceberg: Table Spec