Protocol
Stage the mutation before committing it
The safest write is often the one you can inspect before it becomes a write.
When it fits
- A bulk update can be computed in advance and a wrong write would be costly to reverse.
When to avoid it
- Staging does not remove concurrency, authorization or downstream-trigger risks; account for changes that can occur between preview and commit.
Why it matters
Split the operation into two phases. First generate the proposed changes into a temporary or reviewable form. Validate counts, key fields, invariants and representative examples. Only then apply the verified mutation set. Keep the staged artifact tied to the exact source snapshot so a later apply does not silently target different input.
Steps
- Generate the candidate changes without applying them to the authoritative target.
- Validate the candidate set against explicit business and data invariants.
- Freeze or fingerprint the candidate set and its source snapshot.
- Apply only the reviewed candidate set, then verify the result.
An example
For a mass business-partner update, produce the exact keys and new values first, compare them with source data, then execute that fixed set.
Check your result
The team can inspect exactly what will change before the authoritative state is modified.
Keep this limit in mind
- Staging does not remove concurrency, authorization or downstream-trigger risks; account for changes that can occur between preview and commit.
Connected ideas
Use beforeReconcile what changed after a bulk write
Evidence and sources
Google SRE describes two-phase mutation as storing proposed mutations temporarily, validating them, and applying them only after verification.
Two-phase mutation adds complexity and may not fit every storage system or transaction model.
Improve and Optimize Data Processing Pipelines · Idempotent and Two-Phase Mutations