Once a record can change in two places, you need a resolution rule. Most teams pick one implicitly by writing the sync code first and discovering the rule later, which is how silent data loss ships.
| Strategy | Cost | Fails when |
|---|---|---|
| Append-only | Lowest | Records genuinely need editing after capture |
| Last-write-wins | Low | Two edits race; one is discarded silently |
| Per-field merge | Medium | Fields are semantically coupled |
| CRDT | High | Rarely — but the machinery outweighs the problem for a sign-in form |
A sign-in is an event, not a mutable row. The visitor typed their details at a moment in time; nothing later changes what they typed. Modelling it as an append-only log removes conflicts by construction — there is no second writer to disagree with.
Edits then become new events rather than mutations, and the current state is a fold over the log. You get an audit trail for free, which matters when the data is someone's contact information.
Retries are guaranteed on a flaky connection, so the server must dedupe. Generate a UUID on the device at capture time and use it as the idempotency key. Do not key on (email, listing) — the same visitor can legitimately sign in at two open houses on the same afternoon.