CRDT-Based Catalog Sync: Multi-Cursor Admin Without Conflicts

Two catalog managers editing the same product at the same time is not a theoretical edge case. It is a Tuesday morning for any brand with a dedicated content team. The content writer is updating the description. The catalog manager is updating the price. The inventory team is updating the stock count. They are all in the admin simultaneously, because that is how teams work. The question is not whether concurrent edits will happen — they will. The question is whether the system is smart enough to merge them, or whether it silently picks one and throws the others away.

Most platforms pick one. Last-write-wins is the default resolution strategy, and it means that whoever saved last is right, and whoever saved first had their work silently discarded. For a busy catalog team, this is not an occasional annoyance — it is a productivity tax paid every day.

What CRDTs Are and Why They Matter

Conflict-free Replicated Data Types are data structures with a mathematical property: two instances of the same CRDT, modified independently with any set of operations, will always converge to the same state when those modifications are merged — regardless of the order the operations are applied. There is no 'conflict' to resolve because the merge is always deterministic.

For collaborative text editing (product descriptions, meta descriptions, marketing copy), we use a sequence CRDT that models text as a sequence of characters with unique identities. Inserting a character and deleting a character are operations that compose correctly regardless of order. Two editors can type simultaneously in the same description field and both their inputs will appear correctly in the merged result.

Field-Level CRDT Model

Not all product fields are text. We apply different CRDT semantics per field type:

• Text fields (description, name, meta description): sequence CRDT — concurrent edits merge character-by-character
• Numeric fields (price, compare-at-price, weight): last-write-wins with a vector clock — the 'last' is determined by causal order, not wall clock time, so a network-delayed write does not silently overwrite a later edit
• Set fields (tags, categories): two-phase set CRDT — adds and removes are tracked separately; if two editors concurrently add different tags, both tags appear; if one adds a tag and another removes it concurrently, we prefer add (optimistic) and surface the conflict for human review
• Image galleries: ordered list CRDT — images can be added, removed, and reordered concurrently with convergent results

The Presence Layer

CRDTs handle the data layer. The presence layer handles the social layer — showing editors who else is working on the same product right now. Our admin uses a WebSocket presence channel per product. When an editor opens a product, their cursor appears for other editors. When they focus a specific field, that field shows a colored 'being edited by' indicator.

Presence is not just a UX nicety. It reduces the frequency of concurrent edits because editors naturally coordinate when they can see each other. CRDTs handle the concurrent edits that happen anyway — despite coordination.

Where We Made Pragmatic Tradeoffs

CRDTs are not a universal solution. Some product attributes cannot be merged without domain knowledge:

• GST HSN codes: A product can only have one HSN code. If two editors set different HSN codes concurrently, a CRDT merge produces an ambiguous result. We surface this as an explicit conflict for manual resolution rather than auto-merging.
• Variant matrix structure: Adding and removing product variants (size, color) is complex enough that we serialize variant edits — only one editor can modify the variant matrix at a time, indicated by a presence lock.
• Pricing rules: Promotional pricing with complex rule interactions is serialized at the pricing rule editor level. The CRDT model covers simple fields; complex rule graphs are locked during edit.

Implementation: Yjs Under the Hood

We use Yjs as our CRDT runtime. Yjs is a mature, battle-tested CRDT library with a compact binary encoding, efficient sync protocol, and provider ecosystem for WebSocket and WebRTC transport. Our admin's collaborative editing features are built as Yjs-aware React components — the document is a Yjs document, fields bind to Yjs types, and the WebSocket provider handles sync between editors and persistence to our backend.

The backend stores Yjs document state (the full CRDT history, not just the current value) per product. This enables undo/redo that works across editing sessions and provides a complete history of every edit — who changed what field, when, with microsecond precision.

For a catalog team working on a festival launch — dozens of products being updated simultaneously by multiple team members — this is the difference between a coordinated launch and a chaotic one where half the updates get overwritten. Architecture is calm when the deadline is not.

Subscribe to the QuantumOS Dispatch — weekly insights for commerce operators who want to compound their advantages.