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 storage and reference mechanism must actually support the required atomic change.

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 and define recovery when validation or the switch fails.

Reference: PostgreSQL: Transactions.