Glossary
Optimistic concurrency control
Updating a record only if it hasn’t changed since you read it, usually by checking a version number, so stale decisions aren’t applied.
Also called Compare-and-set, Version check.
In plain terms
Automation often reads state, decides, then acts. If something changes in between, the action is based on a world that no longer exists.
A version check closes that gap. You read version 3, and your write says “only if it’s still version 3.” If someone else changed it, the write fails and you re-check instead of overwriting.
See what happens without it
The failure pattern this protects against, automation acts on stale state or authorization, played out step by step.
Scroll the diagram sideways to see every system.
A customer who cancelled is charged anyway.
What goes wrong:
- At 01:00 the job reads the list of accounts it will bill.
- At 01:20 an admin cancels account #77.
- At 02:00 the job acts on the list it read an hour ago.
- A customer who cancelled is charged anyway.
With the safeguard:
- At 01:00 the job reads the list of accounts it will bill.
- At 01:20 an admin cancels account #77.
- Just before acting, the job re-checks each account’s current version.
- The change is caught and the charge is skipped.
When it mattered
In 2025 a latent race condition in DynamoDB’s DNS automation let an older plan overwrite a newer one, leaving the regional endpoint with an empty DNS record.