How would you design an insert-or-update operation that is safe under concurrent requests?

In production I choose the SQL pattern for the actual database and contention profile rather than assuming one generic MERGE statement is universally safe. On SQL Server, separate insert and update logic can be clearer under heavy concurrency, while the unique constraint remains the final arbiter. I distinguish expected duplicate-key races from unrelated constraint failures and retry only a repeat-safe unit. Concurrency tests release many requests against the same key and assert one row, one logical outcome, and no duplicated side effect. Telemetry tracks conflicts, payload mismatches, retries, and hot keys. If the source operation can be replayed after an uncertain response, I persist the idempotency key and prior response long enough to cover that retry window.