How would you prevent lost updates when two users edit the same row?

In production I choose the conflict boundary from the business invariant. One rowversion protects one row; it does not automatically protect an aggregate spread across order, lines, inventory, and status tables. I may place a version on the aggregate root and update it in the same transaction, use atomic conditional updates for counters, or rely on a stricter transaction strategy where conflicts are common. Automatic retry is safe only when the operation can be recomputed without erasing another user's intent, such as an idempotent state transition with current data; retrying a stale form by simply replacing the token defeats concurrency protection. The response includes stable conflict information and a fresh representation or retrieval path without leaking protected state. I monitor conflict rate by workflow because a spike can reveal an overly broad edit screen, long user think time, duplicate submissions, or a hot aggregate. Tests run two real contexts against the same database, commit both orderings, and verify one stale write cannot win. Audit records capture accepted business changes, while rejected stale attempts are logged only when operationally useful rather than generating noisy permanent history.