A field application has been live for three months and support reports that engineers occasionally lose completed job reports. What do you investigate?
Show the full answer Hide the answer
Suspect last-writer-wins on a record-level merge
The pattern fits exactly. Two writers touch the same record — the engineer's device and the office, or two devices — and the later timestamp wins the whole record, discarding the other side's changes silently.
"Occasionally" is the signature: it only happens when both sides changed the same record within the sync window.
Confirm with the two checks that distinguish causes
Is the losing write reaching the server at all? If the sync log shows it arrived and was superseded, it is a conflict resolution problem. If it never arrived, it is a sync reliability problem — a queue lost to storage eviction, a process termination before flush, or a failed batch that was not retried — and the remedy is completely different.
Whose clock decided? If ordering uses the device timestamp, a device several minutes fast wins every conflict it participates in regardless of the actual order of events. This is a common and under-suspected cause, and it is visible as a correlation between losses and specific devices.
The fixes, in order
Stop ordering by device clock. Use a logical clock or version vector; keep device time as data, not as the ordering key.
Move from record-level to field-level merge, so two writers touching different fields both succeed. This alone removes most real-world conflicts.
Choose the strategy per entity, with the business. A completed job report should never be silently discarded — for that entity the correct behaviour is to preserve both and surface the conflict, even though that is more work.
Protect unsynchronised data from eviction, and never rely solely on a scheduled background task, since the platform may not run it.
What was missing from the start
Telemetry. Because the device cannot be reached, conflicts detected, their resolution and sync outcomes must be reported when connectivity returns — otherwise "occasionally loses reports" is unfalsifiable. Add it now regardless of the cause, because you will need it for the next question of this shape.