Why atomic file publishing is a correctness decision
Direct overwrite and temporary-file rename are not merely two performance variants; they expose different states to concurrent readers and failures.
A JSON file can be valid before an update and valid after an update while still being invalid during the update. That middle state is what atomic publication is designed to remove from the reader’s view.
The ASAMB experiment measures local timing, but the more important comparison is behavioral: what can another process observe if writing is interrupted or if it reads at the same moment?
The two publication models
Direct overwrite opens the destination and replaces its contents in place. During that operation, a reader may encounter an empty, truncated or partially written file, depending on timing and filesystem behavior.
The temporary-file pattern writes a complete sibling file and then renames it over the destination. On the same filesystem, rename is commonly used as the publication boundary: readers see the old complete file or the new complete file rather than the bytes in between.
What the current measurement says—and does not say
In this run, Temporary file + rename recorded the lowest median at 168.69 µs. The measured spread between the slowest and fastest median was 43.63%.
This does not prove that the pattern is always faster. Filesystem type, storage layer, antivirus hooks, mount options, virtualized I/O and sync behavior can alter the result. More importantly, the timing loop does not simulate a crash in the middle of a write.
Atomic rename has boundaries
The temporary file must normally be created on the same filesystem as the destination for rename to provide the expected atomic replacement behavior. Cross-filesystem moves can degrade into copy-and-delete operations.
Permissions, ownership, durability requirements and concurrent writers still need explicit handling. Atomic visibility is not the same as durable persistence after power loss, nor does it replace locking when multiple writers race.
Atomic visibility, write durability and multi-writer coordination are separate properties. Name each one explicitly.
Where the pattern earns its complexity
Configuration snapshots, generated manifests, feeds, cached API documents and deployment metadata are common examples. Readers often assume these files are parseable at every moment. A partial file can cause a larger outage than the few extra operations required to publish safely.
For append-only logs or database-backed state, a different design may be more appropriate. The pattern should follow the reader contract rather than being copied indiscriminately.
Implementation review questions
- Is the temporary file created in the destination directory?
- Are write errors and short writes checked before rename?
- Are permissions and ownership preserved as intended?
- Can multiple writers collide, and is locking required?
- Does the application require fsync-style durability or only atomic visibility?
- How are stale temporary files cleaned after interruption?