Design Offline Sync and Conflict Resolution

Clarified data type (structured records vs docs vs files) and offline duration before designing
Distinguished single-user multi-device vs multi-user collaborative use case
Defined functional scope: offline read/write, push/pull sync, conflict detection/resolution, deletion handling
Stated non-functional targets: eventual consistency, scale (devices/ops), bounded storage via compaction

Designed client-side local store + outbox/op-log for offline writes
Designed server-side sync service performing version/conflict checks separate from entity store
Included append-only change log for delta sync distinct from current-state entity store
Defined push/pull API contract including version/cursor semantics
Included mechanism to wake other devices (notification/push) rather than pure polling

Explained conflict detection approach (optimistic versioning) and at least one resolution strategy (LWW, field-merge, or CRDT) with its trade-off
Addressed causality/ordering problem (vector clocks or Lamport clocks) vs naive timestamps and why clock skew matters
Covered tombstones/soft-delete to prevent deletion resurrection across offline devices
Addressed idempotency/dedup for retried ops (op_id) to survive flaky networks
Discussed when automatic merge isn't possible and escalation to manual resolution

Structured answer with clear requirements → architecture → deep dive progression within time budget
Proactively surfaced trade-offs rather than presenting one "only correct" design
Gave concrete numbers/examples (op volume, retention windows, latency) rather than staying abstract
Delivered a concise, confident closing summary of the design

Problem