What happens when two systems change the same record at the same time?

Why last-write-wins fails in practice

Last-write-wins assumes the later timestamp represents the better information. It usually does not. A nightly batch job carrying yesterday's export finishes at 2am and overwrites a correction a dispatcher made at 4pm. The batch wrote last. The dispatcher was right.

Clock skew makes it worse. Two systems whose clocks differ by even a few seconds will resolve conflicts arbitrarily, and the arbitrariness is invisible because both writes succeeded.

There is also a subtler version. Two systems can each hold a correct value for a record that has genuinely different meanings on each side — the CRM's address is where the customer receives mail, the field service system's address is where the work happens. Last-write-wins destroys one of them and neither was wrong.

Three rules that beat the clock

• Field ownership. The owning system always wins for that field, regardless of timing. Most conflicts stop existing because most conflicts are two systems fighting over a field only one of them should touch.
• Source priority. Rank the writers. A human edit in the operational UI outranks an automated enrichment; an enrichment outranks a bulk import. Encode the rank, not the timestamp.
• Refuse and queue. For high-stakes fields — billing, scheduled time, customer identity — the safest rule is to not resolve automatically. Hold the conflicting write and surface it to a person.

The conflict log is an operations report, not a debug log

Log every conflict with both values, both sources and the rule that decided it. Then read the log monthly. Repeated conflicts on the same field almost never indicate a code problem; they indicate two teams doing the same job in two places.

A common example: the office edits an appointment time in the scheduling board while an automated reminder workflow reschedules from a customer reply. Neither is wrong. The process is. Fixing the process eliminates the conflict permanently, which is a better outcome than a smarter merge rule.

What to do before you have any of this

If you are building the first integration between two systems and none of this exists yet, start with the cheapest possible version: make the integration one-directional, and write only into fields that no human edits. That eliminates the conflict category entirely while you learn how the data actually behaves.

Add bidirectional writes later, deliberately, with the ownership rules written down. That sequencing is standard in our integration work because it puts the hard decisions after you have real data to inform them.