{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigxusiqdo7em37rut65pymnfkbneu4lf2kx2kuigeilivggjdaf7m",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mokd5nojy4b2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihancac4oclu4b775wrnetokl7smkvcluuvawlqf7nrekpvrbqyum"
    },
    "mimeType": "image/webp",
    "size": 67592
  },
  "path": "/software_mvp-factory/crdts-in-kotlin-multiplatform-kill-your-sync-server-28n8",
  "publishedAt": "2026-06-18T07:35:18.000Z",
  "site": "https://dev.to",
  "tags": [
    "webdev",
    "programming"
  ],
  "textContent": "##  What we're building\n\nBy the end of this tutorial, you'll have a working mental model — and working code — for implementing Conflict-Free Replicated Data Types in Kotlin Multiplatform shared code. We'll build an LWW-Register, compare state-based vs operation-based sync strategies, and walk through the architecture that lets you replace your entire sync backend with dumb blob storage.\n\nLet me show you a pattern I use in every project with offline-first requirements.\n\n##  Prerequisites\n\n  * Kotlin Multiplatform project set up with `commonMain`, Android, and iOS targets\n  * Familiarity with Kotlin data classes and basic merge logic\n  * SQLDelight (recommended for local persistence)\n\n\n\n##  Step 1: Understand why custom sync servers fail\n\nMost teams build a centralized arbiter — a server that receives conflicting writes, applies \"last write wins\" at the field level, and hopes for the best. This creates a single point of failure and an ever-growing surface area of edge-case conflict logic nobody wants to maintain.\n\nCRDTs flip the model. Every replica converges to the same state given the same set of updates. Mathematically guaranteed, no coordination required.\n\n##  Step 2: Pick the right primitives\n\nNot every CRDT is practical on constrained devices. Here is the minimal setup to get this working:\n\nPrimitive | Use case | Merge cost | Payload overhead\n---|---|---|---\nLWW-Register | User profile fields, settings | O(1) | Minimal: timestamp + value\nG-Counter | Analytics events, view counts | O(n) where n = replicas | Grows linearly with replica count\nPN-Counter | Inventory, cart quantities | O(n) | 2x G-Counter\nRGA | Collaborative text, ordered lists | O(log n) amortized | Tombstones accumulate over time\nOR-Set | Tags, favorites, selections | O(n) per element | Causal metadata per item\n\nFor most mobile apps, LWW-Registers and OR-Sets cover the majority of sync needs. RGA is only necessary when you need ordered, collaborative sequences.\n\n##  Step 3: Implement an LWW-Register in `commonMain`\n\nOne implementation, every platform. Drop this into your shared module:\n\n\n\n    data class LWWRegister<T>(\n        val value: T,\n        val timestamp: Long,\n        val nodeId: String\n    ) {\n        fun merge(other: LWWRegister<T>): LWWRegister<T> = when {\n            other.timestamp > this.timestamp -> other\n            other.timestamp < this.timestamp -> this\n            else -> if (other.nodeId > this.nodeId) other else this\n        }\n    }\n\n\nThe `nodeId` tiebreaker matters more than people realize. Without it, identical timestamps produce non-deterministic merges, which violates the convergence guarantee. The docs do not mention this, but most tutorials skip this detail entirely.\n\n##  Step 4: Choose state-based vs operation-based\n\nDimension | State-based (CvRDT) | Operation-based (CmRDT)\n---|---|---\nNetwork requirement | Unreliable (idempotent merge) | Exactly-once delivery needed\nPayload size | Full state on each sync | Individual operations\nInfrastructure complexity | Lower: just exchange states | Higher: needs causal ordering layer\nBandwidth on constrained networks | Higher per message | Lower per message\nImplementation difficulty | Simpler merge functions | Requires operation log + delivery guarantees\n\nOn mobile, state-based CRDTs are the pragmatic default. 3G connections drop mid-sync. Apps get backgrounded and sockets die. Requiring exactly-once delivery for operation-based CRDTs means building a reliable causal broadcast layer — which reintroduces the backend complexity you were trying to escape.\n\nIf your documents grow large, delta-state CRDTs offer a hybrid approach: transmit only the state diff since last sync, reclaiming bandwidth without sacrificing idempotency.\n\n##  Step 5: Handle vector clocks without fear\n\nVector clocks track causal ordering across replicas. Here is the gotcha that will save you hours: on mobile, the constraint is friendlier than it sounds. Most users have a bounded number of devices. A vector clock with entries for a phone, tablet, and laptop is three integers. That's nothing.\n\nPrune entries for devices inactive beyond a threshold, and the metadata stays compact. Store vector clocks alongside each CRDT in SQLDelight, and compare them during sync to detect concurrent updates versus causal successors.\n\nFor Automerge integration, wrap the native Rust-based library via `expect`/`actual` declarations — JNI on Android, C interop on iOS through the shared boundary.\n\n##  Step 6: Delete your sync service\n\n\n    ┌──────────┐     ┌──────────┐     ┌──────────┐\n    │ Android  │     │   iOS    │     │ Desktop  │\n    └────┬─────┘     └────┬─────┘     └────┬─────┘\n         │                │                │\n         │   CRDT State Blobs (opaque)     │\n         └────────┬───────┴───────┬────────┘\n                  ▼               ▼\n            ┌───────────────────────┐\n            │   Dumb Storage Relay  │\n            │  (S3 / Cloud Storage) │\n            │  No conflict logic    │\n            └───────────────────────┘\n\n\nYour \"backend\" becomes a storage relay. It holds opaque CRDT state blobs, knows nothing about your data model, resolves zero conflicts, and scales with commodity object storage pricing. You delete the sync service, its tests, its deployment pipeline, and its on-call rotation.\n\n##  Gotchas\n\n  * **Missing`nodeId` tiebreaker**: Without deterministic tiebreaking on equal timestamps, your LWW-Register violates convergence. Always include it.\n  * **Reaching for operation-based CRDTs too early** : They require exactly-once delivery guarantees. On mobile networks, that means building infrastructure you were trying to avoid.\n  * **Optimizing payload size before measuring** : State-based payloads for typical mobile data sets (preferences, local lists, document fragments) stay well within acceptable bounds. Reach for delta-state variants only when payload sizes become a measured problem, not a theoretical one.\n  * **Overestimating vector clock overhead** : You're not running thousands of nodes. You're tracking three devices.\n\n\n\n##  Conclusion\n\nStart with LWW-Registers and OR-Sets in `commonMain`. These two primitives cover user settings, favorites, tags, and most entity-level sync needs. Write platform-agnostic property tests that verify convergence. Default to state-based CRDTs — the idempotent merge model tolerates unreliable networks without additional infrastructure.\n\nOnce your clients can independently merge state, your backend doesn't need conflict resolution logic anymore. Reduce it to authenticated blob storage and spend that engineering time on product work instead.",
  "title": "CRDTs in Kotlin Multiplatform: Kill Your Sync Server"
}