What they're testing
Whether you recognise this as a product decision before it's a technical one.
The short answer~30 seconds
From cheap to expensive: last-write-wins (simple, and silently loses data); pessimistic locking — whoever opens first, everyone else reads (clear but irritating, and you must handle abandoned locks); version-based conflict detection where the loser resolves it (the sensible default for most applications); and finally automatic merging with CRDTs or OT — the Google Docs experience, and considerably more expensive than it looks.
The long answer
The first step should be asking about conflict granularity. A great many "conflicts" disappear if you track by FIELD rather than by document: two people editing different fields of the same form don't actually conflict, but an API that sends the whole object turns it into one. Sending only changed fields (JSON Patch, or just the dirty ones) removes most cases with no clever machinery at all.
If you choose conflict detection, the hard part isn't detecting but the INTERFACE for resolving it. Returning a 409 and showing "someone else edited this, please reload" reliably discards what the user just typed. At minimum you must show the difference and keep their draft. This is where teams implement the backend correctly and still ship something annoying.
What they'll ask next
?Is a CRDT always better?
No. It merges without a server adjudicating, but its metadata grows with edit history, and "mergeable" doesn't mean the result makes business sense — two people setting an order status to different values will merge into one that neither intended.
These lose points
- Last-write-wins without acknowledging that it loses data. It's a legitimate choice; hiding the consequence isn't.
Sources
- Martin Kleppmann, Designing Data-Intensive Applications, ch. 5 — handling concurrent writes
- MDN — `If-Match` and ETags for conditional updates