Avoid lost updates on Kubernetes writes using resourceVersion optimistic concurrency

Documented steps

1. GET the object and record .metadata.resourceVersion — a server-assigned opaque string that changes on every write to that object.
2. Compute the modified object locally, preserving the resourceVersion you read.
3. For a full replace, send PUT with .metadata.resourceVersion included. The server accepts the write only if it still matches the live object.
4. If the resourceVersion is stale because another writer changed the object, the API server returns 409 Conflict.
5. On 409, re-GET the object to obtain a fresh resourceVersion, recompute the change against the new state, and resend. Kubernetes always detects the conflict, but implementing the retry loop is the client's responsibility.
6. Bound the retry loop with exponential backoff and a max attempt count so a hot object cannot spin forever.
7. For PATCH, optimistic concurrency is opt-in: use application/json-patch+json with a 'test' operation asserting the current value, which fails the request if the assertion does not hold.
8. Alternatively include metadata.resourceVersion inside a merge-patch body to make the patch conditional on the object being unchanged.
9. For controller-style reconciliation, prefer Server-Side Apply instead — it needs no resourceVersion and detects conflicts per field via managedFields.
10. Docs: https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions