Mobile Offline-First Sync

The user opens your app on the subway. No signal. They write a comment, mark a task done, edit a doc. The app should accept their work, not pop "no internet" errors. When connectivity returns, everything they did syncs to the server. That's offline-first — and it's vastly harder than it sounds.

Two phones edit the same doc while both offline. They reconnect. Whose change wins? What if both add a row with the same primary key? What if one phone deleted what the other modified? These are the hard problems mobile apps face and most get partially wrong.

1. Local-first storage. SQLite (Android Room, iOS Core Data, Realm). All reads + writes go to local DB first.
2. Operation queue. Writes also append to a pending-operations queue. "Comment created", "Task done", "Doc edited at offset 42 inserted X."
3. Sync engine. When online, drains the queue to the server. Server returns canonical state. Local DB updated.
4. Conflict resolution. Server's authoritative answer might disagree with local optimistic state. Reconcile.
5. Pull updates. Server pushes (or device pulls) changes from other clients. Apply to local DB. UI updates reactively.

UI never sees "loading" for normal interactions — it reads from local DB, optimistic. Network is a background concern that eventually reconciles.

class GCounter:
    """Each replica tracks its own contribution; total = sum."""
    def __init__(self, replica_id):
        self.replica = replica_id
        self.counts = {replica_id: 0}

    def inc(self, n=1):
        self.counts[self.replica] += n

    def value(self):
        return sum(self.counts.values())

    def merge(self, other):
        for r, v in other.counts.items():
            self.counts[r] = max(self.counts.get(r, 0), v)
        return self

# Two phones increment offline; reconnect; merge = sum of each replica's
# own count. Associative, commutative, idempotent. No conflict resolution needed.

# PN-Counter = two G-counters (inc + dec). Supports decrement.

OT requires every operation to be transformed against every concurrent operation — server-side coordination, complex correctness proofs (Google Docs took years to get right). CRDTs (Conflict-free Replicated Data Types) are data structures that mathematically merge regardless of order or duplication. Two clients can apply operations in any order and converge to the same result.

Concrete CRDTs:

• G-Counter — grow-only counter. Each client tracks its own delta. Sum = total.
• OR-Set — observed-remove set. Add and remove operations carry unique tags so concurrent add+remove is unambiguous.
• RGA / LSEQ — sequence types for collaborative text. Each character has a unique position-ID; concurrent inserts produce deterministic ordering.
• YATA / Yjs — practical CRDT library used by ~all 2024-era collab apps. Powers Linear's editor, the Notion clones, Tldraw, Liveblocks.

The win: zero server-side conflict resolution code. Client A and Client B both run the same merge logic locally; results converge. Server is just a relay + storage. Same code can run peer-to-peer (some apps do this).

• Use stable client-side IDs. Generate UUIDs locally; don't wait for server-assigned IDs. Server stores client UUIDs; deterministic across sync.
• Vector clocks for "since when?" Each client tracks "I last synced at vector V"; server returns ops since V. Avoids re-syncing the world.
• Idempotent operations. Same op applied twice = no double effect. Survives the inevitable retry.
• Handle deletions specially. "Tombstone" markers prevent zombies (deleted item recreated by another client's old write).
• Conflict-resolution UI for genuine human conflicts. Two people edit the same paragraph — show both versions, let user pick. Don't pretend you can auto-resolve everything.
• Battery + bandwidth. Don't poll; use long-poll or push. Sync when on WiFi if possible. Coalesce batches.

Google Drive sync engine is a textbook offline-first system. Google Docs uses OT for character-level collaboration. WhatsApp messages queue locally when offline; deliver on reconnect. Notification system relies on push protocols + offline buffering.