Concurrency control
Every writer must join the new concurrency protocol
Adding revision checks to one endpoint leaves older jobs able to overwrite it. Roll out the protection across the complete set of writers.
In this article
Inventory the mutation paths
List web requests, imports, scheduled jobs, administrative scripts and direct integrations that change the protected data. Identify their deployed versions and owners.
For a version-check scheme, establish how each writer reads and advances the revision. A writer that updates fields without advancing it makes later comparisons unreliable.
Do not assume low-volume paths are harmless. A monthly import can overwrite many carefully protected interactive edits in one run.
Introduce compatible metadata
Add the required revision or operation fields in a way existing code can tolerate. Initialise historical records under a clear rule and update writers before claiming that the protection is complete.
During the transition, observe paths that omit the required precondition. Decide whether they remain temporarily supported under a restricted policy or must be stopped before enforcement.
Avoid silently filling a missing expected revision with the current one. That makes old clients appear compliant while preserving their unconditional overwrite behaviour.
Enforce in a controlled scope
Enable rejection for an initial set of compatible callers and inspect conflict handling. Confirm that the interface preserves drafts and background jobs record recoverable outcomes.
Exercise retries after timeouts and deployment rollback. A previous application version that cannot supply the precondition may no longer be a viable rollback target once enforcement is mandatory.
Keep that boundary explicit in release coordination. A database field existing successfully does not mean every running process understands its purpose.
Close the bypasses
Require the protocol for all relevant writers once migration conditions are met. Restrict direct database access that could bypass the application invariant, while retaining a reviewed repair procedure for exceptional work.
Monitor missing preconditions and unexpected revision behaviour after rollout. These signals can reveal forgotten consumers.
Finish with a deliberate race between different writer types, such as a user edit and an import. The rollout is complete when the shared rule survives across the system, not merely when the main API returns a conflict in a unit test.
Primary sources
HTTP semantics: conditional requestsPostgreSQL: privilegesReferences checked 11 September 2026.