Design an API operation that updates one database record safely under retries and concurrent writers. The client sends a record ID, expected version, proposed new value, and idempotency key. Apply the update only if the current version matches and the new value passes validation. A retry with the same idempotency key and same request must return the original result. A failed multi-step update must leave no partial state. ### Constraints & Assumptions - An idempotency key cannot be reused for a different payload. - Successful updates increment the record version exactly once. - Validation that affects correctness must run inside the transaction or be protected from time-of-check/time-of-use drift. ### Clarifying Questions to Ask - What result should a stale expected version return? - Does the update touch dependent rows or emit an external event? - How long are idempotency records retained? ```hint Treat the idempotency result as data Persist the key, a canonical request hash, and the committed response in the same transaction as the update. ``` ### What a Strong Answer Covers - Conditional update or row lock, transactional validation, version increment, and rollback. - Idempotency-key conflict detection and response replay. - An outbox for external side effects, precise error classes, and concurrency tests. ### Follow-up Questions - What if the process crashes after commit but before responding? - How would you publish an update event exactly once from the database's perspective? - How would bulk updates change the transaction boundary?