CRDT Digital Twin Synchronization: Offline-First State Replication at the Edge

A digital twin that lives in one cloud database is a fiction the moment a factory uplink drops. The edge twin keeps ingesting telemetry, an operator at the cell tablet keeps annotating, and the cloud twin keeps receiving writes from analytics jobs. When the link returns, you have two histories of the same asset and no obvious answer to the question “which one is true?” Most teams answer with last-write-wins on a wall-clock timestamp, and most teams eventually discover that a clock skewed by a few seconds silently deleted a maintenance flag.

CRDT digital twin synchronization replaces that guesswork with a mathematical guarantee: replicas that have seen the same set of updates hold the same state, regardless of delivery order or duplication. This is not a free lunch. It works for some kinds of twin state and is actively dangerous for others, and the boundary is the interesting part.

What this covers: the replication problem in edge-cloud twins, the three CRDT families (state, operation, delta), LWW registers with hybrid logical clocks, OR-Sets and counters, causal delivery, tombstone growth, the library landscape (Automerge, Yjs and others), a runnable Python twin property map, where CRDTs are the wrong tool, and how the approach compares to event sourcing.

Context and Background

Digital twin platforms were designed around a cloud-centric assumption: devices publish telemetry, a broker fans it in, and a single authoritative store holds the twin. That model is simple to reason about because one database serializes every write. It also means the twin is only as available as the WAN link, and that every edge consumer, such as a local control loop, a safety dashboard or an operator tablet, pays a round trip to read the state of the machine standing next to it.

Real deployments break the assumption in three ways. Plants run on cellular or satellite backhaul with multi-hour outages. Regulatory or latency constraints force a local twin that must keep working in isolation. And twins are increasingly written to by more than the device itself: maintenance systems, simulation outputs, and AI agents of the kind discussed in our piece on AI-driven digital twins as autonomous decision engines all write back into twin state. Multi-writer, partitioned, eventually connected: that is the exact environment where classical primary-copy replication either blocks or loses data.

Distributed systems theory frames this as the CAP trade-off. When a partition occurs you either refuse writes on one side (consistency) or accept them everywhere and reconcile later (availability). Edge twins almost always choose availability, so the real question is how reconciliation happens. Ad hoc reconciliation, usually timestamp comparison buried in an ingest service, is where data corruption hides.

Conflict-free replicated data types are the principled answer. The concept was formalized by Marc Shapiro, Nuno Preguica, Carlos Baquero and Marek Zawirski in their 2011 study of convergent and commutative replicated data types, and the community reference site crdt.tech describes the goal plainly: replicas can change independently, even offline, and merge automatically into a consistent state without custom conflict-resolution code and without a central server. The guarantee is called strong eventual consistency: any two replicas that have received the same set of updates are in the same state, with no coordination.

A related and complementary problem is estimating the true physical state behind noisy, delayed measurements; that is the territory of our guide to Kalman and particle filter twin synchronization. State estimation answers “what is the machine really doing?”. CRDTs answer a different question: “how do N copies of our record of the machine agree?” Keeping those two concerns separate is the first design decision in this article.

Reference Architecture: Replicas, Deltas, and a Join

The core idea in one paragraph: model each piece of twin state as a data type with a merge function (a join) that is commutative, associative and idempotent. If merge has those three properties, replicas can exchange state in any order, with duplicates, over lossy links, and still converge. Everything else in this article, clocks, tombstones, delta buffers, is machinery for building types that really do satisfy those laws while remaining useful.

Figure 1: A three-tier twin topology where every tier holds a full replica and replicas exchange deltas pairwise. No tier is authoritative.

Figure 1 shows the topology. The edge replica sits beside the machine and feeds a local control loop. A gateway replica aggregates a cell or line. The cloud replica serves analytics and cross-site views. Each link is bidirectional and independent: the edge can sync with the gateway while the gateway is cut off from the cloud, and the cloud will still converge later because the gateway relays accumulated deltas. The operator application writes to whichever replica is reachable.

The three CRDT families

There are two classical formulations, and a third that is the practical choice for twins.

State-based CRDTs (convergent, CvRDT) ship the entire state and merge by a join function over a semilattice. They tolerate message loss, duplication and reordering with essentially no delivery assumptions, which is ideal for flaky links. The cost is bandwidth: shipping the full state of a twin with thousands of properties every sync is wasteful.

Operation-based CRDTs (commutative, CmRDT) ship small operations, such as “set property X” or “add tag Y”. Messages are tiny, but the transport must deliver every operation exactly once and in causal order. That is a strong requirement to put on an intermittent MQTT or HTTP path, and it pushes complexity into the messaging layer.

Delta-state CRDTs combine both. Almeida, Shoker and Baquero introduced them in the paper Delta State Replicated Data Types, which describes how delta mutators produce small delta states that are merged with local and remote replicas. In the authors’ words the design merges the small incremental messages of operation-based CRDTs with the tolerance of unreliable channels that state-based CRDTs offer. The paper also specifies anti-entropy algorithms for eventual convergence and for causal consistency, plus a generic map composition, which is precisely the shape of a twin’s property bag.

Figure 2: State, operation and delta CRDTs differ in what travels on the wire and in what the transport must guarantee. All end at the same converged replica.

Figure 2 summarizes the trade. Deltas are themselves states, so they can be merged with the same join and are safe to duplicate or reorder. Because they are small, you can sync a changed property rather than the whole twin. An anti-entropy layer, which tracks which deltas each peer has acknowledged and resends the rest, supplies reliability.

Why a join works for twin state

Consider the join requirement in terms of a single property such as a temperature setpoint. Replica A says 72 at some timestamp, replica B says 70 at an earlier timestamp. Define merge as “keep the entry with the greater timestamp”. That function is commutative (order of arguments does not matter), associative (grouping does not matter) and idempotent (merging the same entry twice changes nothing). Those three laws are the whole proof obligation, and they are why you can retry and reorder freely.

The rest of the design is deciding, per property, which join semantics match the meaning of the data. A last-write-wins register is correct for “latest reading”. It is wrong for “set of active alarms”, where two concurrent additions must both survive, and wrong for “cycles completed”, where two concurrent increments must both count. Section by section, the next part of the article builds the vocabulary for making those choices.

Mapping twin state to CRDT types

A practical twin document decomposes into a handful of recurring shapes. Scalar properties with a clear “current value” semantic, such as setpoints, firmware version strings and operating mode labels, use LWW registers. Membership collections, such as tags, active alarm identifiers and the set of attached sensors, use OR-Sets. Monotone or bidirectional tallies, such as parts produced, fault counts and energy consumed in a shift, use counters. Nested structure, such as a component tree, uses a map CRDT whose values are themselves CRDTs, which is the map composition the delta paper formalizes.

What you deliberately do not put in a CRDT is high-rate raw telemetry. A vibration stream sampled at kilohertz rates is an append-only time series, and the right home for it is a time-series store with its own replication. The CRDT holds the twin’s slowly changing state and annotations, plus perhaps the latest summarized value of each signal. Keeping the CRDT document small is what makes full-state fallback syncs cheap and keeps tombstone overhead (discussed later) bounded.

Deeper Analysis: Clocks, Sets, Counters, and a Runnable Twin

LWW registers and why wall clocks fail

A last-write-wins register stores a value and a timestamp, and merge keeps the larger timestamp. The scheme is attractive because it needs one comparison and no per-value history. Its failure mode is the timestamp source. If edge devices stamp writes with time.time(), a device whose clock runs thirty seconds fast will win every conflict for thirty seconds, even against a genuinely later write from a correct clock. Worse, a device that boots with its real-time clock reset to an epoch default can lose every write until NTP corrects it, so its legitimate updates are silently discarded as “older”.

Hybrid logical clocks (HLC), proposed by Sandeep Kulkarni, Murat Demirbas and colleagues, repair the worst of this. Per the original HLC paper, each node keeps a pair: l, the largest physical clock value it has learned about directly or through messages, and c, a counter that orders events sharing the same l. Timestamps compare lexicographically on (l, c). On a local or send event, the node sets l to the greater of its old l and its physical time, incrementing c if l did not move and resetting it otherwise. On receive, l becomes the maximum of its old value, the message’s value and physical time, and c is adjusted according to which of those matched.

Two properties matter for twins. First, HLC timestamps respect causality: if an edge replica receives a delta and then writes, its write is guaranteed to be ordered after the received one, even if its physical clock is behind. Second, l stays close to physical time, so timestamps remain meaningful to humans and usable for time-range queries. The paper proposes packing l into 48 bits and c into 16 bits for a 64-bit timestamp, with the 16-bit counter’s 65,536 values reported as sufficient in its experiments.

HLC does not make concurrent writes disappear. Two writes that are truly concurrent still need a deterministic winner, so production implementations append a node identifier as a final tiebreaker, making the order total. The loser is not wrong in any physical sense; the system has simply chosen a convention. That convention must be one you are willing to defend for the data in question, which is why the choice of register type per property matters.

The OR-Set: add-wins membership

Plain set CRDTs struggle with the add-remove race. If replica A removes element x while replica B concurrently adds x, what is the right outcome? The observed-remove set (OR-Set) answers by tagging every add with a unique identifier. A remove deletes only the add-tags the remover has observed. A concurrent add carries a tag the remover never saw, so it survives, giving “add-wins” semantics.

For twins this is usually the right default. A maintenance flag raised at the edge while the cloud concurrently clears the previous flag should not be lost. The cost is that removal state, the set of removed tags (tombstones), accumulates, which we return to in the garbage collection discussion.

Counters

A grow-only counter (G-Counter) keeps one non-negative slot per replica and defines the value as the sum; merge takes the element-wise maximum. Two PN-style variants pair a G-Counter of increments with one of decrements to support subtraction. Counters are exactly right for “number of door cycles” or “faults observed”, and exactly wrong for “current inventory in a bin” if you need a non-negative bound, because two replicas can each decrement the last unit concurrently. That is an invariant violation, discussed in the limits section.

Slot-per-replica growth is a cost worth planning for. If every ephemeral edge container gets a fresh replica identifier, the counter accrues a slot per identifier forever. Use stable identifiers tied to the physical gateway or device, not to process lifetime.

Causal delivery and anti-entropy

Delta-state and state-based designs converge without causal delivery, but you often want it anyway so that a reader never observes an effect before its cause, for example a “calibration applied” annotation visible before the “recalibration requested” event it answers. The delta paper’s causal anti-entropy variant achieves this by tagging deltas with a sequence and delivering only when the dependencies are satisfied; the simpler variant gives convergence only.

In practice the anti-entropy loop is straightforward. Each replica keeps a buffer of recent deltas with sequence numbers and a per-peer acknowledgment map. On reconnect, it sends the peer everything after the peer’s acknowledged sequence, or, if the buffer was trimmed beyond that point, falls back to a full state transfer. The delta buffer is therefore a tunable resource: larger buffers survive longer outages without falling back to full state, at the price of memory on a constrained edge device.

Figure 3: During a partition the edge sets a setpoint and adds a tag while the cloud sets a different setpoint and removes the tag. After the link returns, both replicas hold the same state.

Figure 3 traces the worked example we will run next. The cloud’s clock is ten milliseconds behind, the edge’s write wins the setpoint conflict, and the edge’s concurrent tag addition survives the cloud’s removal because the cloud never observed that add.

A runnable twin property map with HLC

The following Python implements a hybrid logical clock, an LWW-register map and an add-wins OR-Set, with deltas as plain dictionaries. It is deliberately minimal and not production code: it omits persistence, delta buffering and garbage collection. The clock injection (now=) lets you simulate skewed devices deterministically.

from __future__ import annotations
import time
from dataclasses import dataclass

@dataclass(frozen=True, order=True)
class HLC:
    l: int      # physical component, milliseconds
    c: int      # logical counter
    node: str   # tiebreaker, makes the order total

class Clock:
    def __init__(self, node, now=lambda: int(time.time() * 1000)):
        self.node, self.now, self.l, self.c = node, now, 0, 0
    def tick(self):
        pt = self.now()
        if pt > self.l:
            self.l, self.c = pt, 0
        else:
            self.c += 1
        return HLC(self.l, self.c, self.node)
    def recv(self, t):
        pt = self.now()
        new_l = max(self.l, t.l, pt)
        if new_l == self.l == t.l:
            self.c = max(self.c, t.c) + 1
        elif new_l == self.l:
            self.c += 1
        elif new_l == t.l:
            self.c = t.c + 1
        else:
            self.c = 0
        self.l = new_l
        return HLC(self.l, self.c, self.node)

class TwinMap:
    """LWW-register map plus an OR-Set of tags; deltas are plain dicts."""
    def __init__(self, node, now=None):
        self.clock = Clock(node, now) if now else Clock(node)
        self.regs = {}                 # key -> (HLC, value)
        self.tags_add = {}             # tag -> set of unique add ids
        self.tags_rem = set()          # removed add ids (tombstones)
        self.seq = 0
    def set(self, key, value):
        ts = self.clock.tick()
        self.regs[key] = (ts, value)
        return {"regs": {key: (ts, value)}}
    def add_tag(self, tag):
        self.seq += 1
        uid = (self.clock.node, self.seq)
        self.tags_add.setdefault(tag, set()).add(uid)
        return {"add": {tag: {uid}}}
    def remove_tag(self, tag):
        seen = set(self.tags_add.get(tag, ()))
        self.tags_rem |= seen
        return {"rem": seen}
    def tags(self):
        return {t for t, ids in self.tags_add.items() if ids - self.tags_rem}
    def merge(self, delta):
        for k, (ts, v) in delta.get("regs", {}).items():
            self.clock.recv(ts)
            if k not in self.regs or ts > self.regs[k][0]:
                self.regs[k] = (ts, v)
        for t, ids in delta.get("add", {}).items():
            self.tags_add.setdefault(t, set()).update(ids)
        self.tags_rem |= delta.get("rem", set())
    def view(self):
        return {k: v for k, (_, v) in self.regs.items()}, self.tags()

if __name__ == "__main__":
    edge, cloud = TwinMap("edge", lambda: 1000), TwinMap("cloud", lambda: 990)
    d1 = edge.set("setpoint_c", 72.0); d1b = edge.add_tag("maintenance")
    d2 = cloud.set("setpoint_c", 70.0); d2b = cloud.add_tag("maintenance")
    d3 = cloud.remove_tag("maintenance")
    for d in (d2, d2b, d3): edge.merge(d)
    for d in (d1, d1b): cloud.merge(d)
    for d in (d1, d1b): cloud.merge(d)   # idempotent redelivery
    print(edge.view()); print(cloud.view()); assert edge.view() == cloud.view()

Running it prints ({'setpoint_c': 72.0}, {'maintenance'}) on both replicas, and the final assert passes. Several things happened. The edge setpoint (HLC physical 1000) beat the cloud’s (990), which is the LWW outcome. Both sides added a “maintenance” tag with distinct identifiers; the cloud then removed only the tag it had observed (its own). The edge’s tag identifier was never observed by the remover, so it survives, which is add-wins. The duplicate delivery of the edge deltas changed nothing, which is idempotence in action.

Notice what the example does not protect you from: if the cloud had been the replica with the faster clock, its stale 70.0 would have won, and the system would be perfectly consistent and perfectly wrong from the operator’s point of view. Convergence is not correctness. It guarantees that everyone agrees, not that the agreed value is the one you wanted.

Comparing LWW, event sourcing, and CRDT maps

Event sourcing stores an immutable log of facts and derives state by folding it. It is excellent for audit, replay and temporal queries, and our discussion of async processing architecture patterns covers the queueing side of that approach. Its weakness for multi-master edge writes is that the fold must resolve conflicts, and a naive fold is just last-write-wins again with extra steps.

Property	Wall-clock LWW	Event sourcing with central log	CRDT map with HLC
Works fully offline at edge	Yes, with data loss risk	Local log only, merge needs rules	Yes, converges by construction
Concurrent update handling	Silent overwrite	Defined by fold logic	Defined by per-type join
Needs central sequencer	No	Usually yes for total order	No
Audit and replay	Poor	Excellent	Limited unless history is kept
Clock-skew sensitivity	High	Low if sequencer stamps	Moderate, bounded by HLC
Storage growth	Constant	Unbounded without compaction	Grows with tombstones and metadata
Safe for invariants	No	Yes with a single writer	No, without extra coordination

The two approaches combine well. Keep CRDTs for converging mutable state and publish an event stream of notable transitions for audit. Do not try to make one replace the other.

Libraries, Tombstones, and Operating a CRDT Twin

The library landscape

You rarely implement CRDTs from scratch; the subtle bugs live in sequence types and garbage collection. Two libraries dominate JavaScript-centric work, and both are network agnostic.

Automerge describes itself as a library of data structures for building collaborative applications, with local-first operation: each device keeps a full local copy that can be edited offline and saved to disk. Its documentation lists JavaScript (Node.js, Electron, browsers, with TypeScript definitions) and a Rust core that compiles to WebAssembly and exposes a C API for platforms without a JavaScript engine, plus Swift API docs. Sync is transport-independent: WebSocket, WebRTC, Bluetooth, or even an emailed file or USB drive, with network bindings supplied by the separate automerge-repo library. For twins, the interesting property is that Automerge documents are JSON-like trees of maps, lists, text and counters, which matches the shape of a twin document.

Yjs is positioned as an engine for collaborative applications with shared types that behave like ordinary data structures. It separates connection providers (y-websocket, y-webrtc and others) from persistence providers (y-indexeddb, y-leveldb, y-redis and others), which maps cleanly onto an edge gateway that persists locally and syncs upstream when it can. Yjs is heavily oriented toward collaborative text and structured documents; that is a fit for operator notes and runbooks attached to a twin, and a less obvious fit for a flat property store.

Both projects are built for human-scale editing. Neither publishes a guarantee about how many thousands of properties per second a device twin can absorb, and I have not found vendor benchmarks for high-rate IoT workloads, so treat throughput as something you measure with your own document shape. Other CRDT implementations are catalogued on the crdt.tech implementations page; I have not evaluated them here and make no claim about their maturity. If your edge runtime is Python, Go or an embedded target, expect to either bind to a Rust core or implement the small subset in this article (registers, OR-Sets, counters, delta buffer) yourself.

Tombstone growth and garbage collection

Every convergent type pays a metadata tax. The OR-Set above never forgets a removed tag identifier; a map that supports key deletion keeps a marker so a late delta cannot resurrect the key. For a twin that lives for years and churns through alarm identifiers, that metadata can dwarf the payload.

Safe garbage collection requires knowing that every replica has seen a removal, so that no future delta can reference the removed element. That is a coordination problem, and CRDTs by design avoid coordination. Practical options are:

Stable-point GC. Track a version vector per peer; once all known peers have acknowledged past a point, tombstones before it can be dropped. This fails when a peer disappears permanently or silently, because the stable point stops advancing.
Epoch reset. Periodically snapshot the converged state, bump an epoch number, and require replicas to rebase onto the snapshot. Replicas that return after being offline across an epoch must discard or re-import their divergent changes. This is coordination, but infrequent and out of the hot path.
Bounded-lifetime design. Avoid unbounded sets in the CRDT. Put alarm history in a log with retention, and keep only the current active alarm set in the CRDT.
Replica retirement. Provide an explicit decommission step that removes a dead replica from the peer list so it no longer blocks the stable point.

A related cost is history. Libraries that preserve full change history for merge correctness grow with edit count even when the visible state is small; compaction features exist, but check what each library retains before putting a long-lived, frequently overwritten property inside it. A setpoint that is rewritten every second for a year is a very different load from a document edited by a person.

Delivery topology and a capacity sketch

Consider an illustrative sizing, labelled as arithmetic rather than measurement. Suppose a twin document holds 2,000 scalar properties and each LWW entry costs roughly 40 bytes of key, value and timestamp on the wire. A full-state sync is then about 80 KB. If only 20 properties change per minute, a delta sync moves around 800 bytes per minute, a hundredfold reduction, which is the entire economic argument for delta-state over state-based replication on a metered cellular link.

Now add the cost of a lost link. If the gateway buffers deltas for six hours and 20 properties change per minute, it holds 7,200 delta entries, about 288 KB at the same entry size. That is trivially affordable on a gateway, but the arithmetic changes if each change carries a 2 KB payload, so cap the buffer by bytes and fall back to a full-state sync, not by time alone. The same reasoning applies to a fleet: with a hundred sites each syncing independently, the cloud replica is a hub of a hundred pairwise sessions, so keep per-site documents rather than one global document that every site must merge.

Fleet rollout interacts with this design. When you update the twin schema or the sync agent across a fleet, you want staged, observable rollouts, a topic we cover in Argo Rollouts progressive delivery for edge fleets. Schema changes are the hard part for CRDTs: a replica running the old type definition must still merge deltas written by the new one, so make changes additive, never change the meaning of an existing key, and version the document format explicitly.

Where CRDTs Are the Wrong Tool

Invariants and physical-control commands

CRDTs guarantee convergence, not application invariants. Any rule of the form “this value must never exceed X” or “exactly one holder of this lock” cannot be enforced by independent replicas, because each makes its decision without seeing the others. Two replicas that each see “valve position 40” and each add 40 more percent through concurrent counter increments will converge on 120 percent; they agree, and the agreement is physically impossible.

Figure 4: Route each write by its meaning. Anything bounded by a safety invariant leaves the CRDT path and goes through a single writer with acknowledgement.

This is the most important design rule in the article. Commands that actuate physical equipment, such as opening a valve, starting a motor or changing a safety interlock, need a single authority and an acknowledged command-response protocol, not an eventually consistent merge. Treat the CRDT as the replicated record of desired and reported state for low-risk properties, and keep the command channel separate. A twin that merges two operators’ conflicting setpoints into a value neither intended is a hazard, not a convenience.

This is also why “desired state” and “reported state” should be distinct keys, as in the device-twin models of the major IoT platforms. Reported state is written by the device and is naturally single-writer per key. Desired state may have several writers and deserves explicit arbitration, such as a priority field or a lease, ahead of any merge.

Other poor fits

Large binary payloads, such as CAD models or firmware images, should be stored as content-addressed objects with only the hash in the CRDT. High-rate time series belongs in a time-series store, as noted earlier. Data with strict privacy deletion obligations is awkward because tombstones and retained history can keep content recoverable, so confirm that your library supports true purge before storing personal data in a replicated document. And workloads with a trustworthy central sequencer and always-on connectivity gain little: a conventional transactional database is simpler and gives you invariants for free.

Trust and security

Standard CRDTs assume replicas are honest. A compromised or buggy replica can emit a delta with an enormous timestamp, and under LWW that value would win against every legitimate write until time catches up. HLC mitigates accidental drift but not malice. Bound acceptable timestamps (reject deltas whose physical component exceeds local time by more than a configured skew), authenticate every peer, and sign or authorize deltas at the transport layer. Per-property write permissions enforced at the gateway are a sound pattern.

Trade-offs, Gotchas, and What Goes Wrong

The failures I see most often are not exotic. They are mismatches between a data type’s merge semantics and what the business meant.

Silent loser. LWW discards one of two concurrent writes without telling anyone. If a human wrote the losing value, they will not know. Surface conflicts for human-edited fields by storing both values in a multi-value register and letting a person pick, or log every overwritten concurrent value to an audit stream.

Skew amplification. A device with an RTC stuck far in the future poisons LWW registers. Clamp incoming timestamps and alert on large HLC drift between peers; the drift metric is also an excellent early signal of failing time sync.

Resurrection. If tombstones are garbage collected too early, a replica returning from a long outage can reintroduce deleted elements. Define a maximum offline duration, and force a full resync for replicas beyond it.

Metadata bloat. Slot-per-replica counters, version vectors and tombstones all grow with the number of replicas and the age of the document. Monitor serialized document size per twin as a first-class metric.

Interleaving and intent. Sequence CRDTs for text can interleave concurrent insertions in surprising ways. For operator notes this is tolerable; for structured data such as ordered recipe steps, prefer a map keyed by step identifier with a position field, and validate the result.

Convergence without validation. A merged document may violate schema constraints that each replica individually respected. Validate on merge and have a defined repair path, for example quarantining the offending property and falling back to the last valid value.

Debuggability. Because the merged state is a function of the set of deltas, not of any single write, answering “why does the twin say 72?” requires provenance. Keep the HLC and writing node with every register value, as the example does, and expose them in your tooling.

The fundamental trade is that you exchange coordination for metadata and for the discipline of choosing semantics per field. Teams that skip the second part end up with a consistent system that is consistently wrong.

Practical Recommendations

Start by classifying every twin property into one of four buckets: single-writer reported state, multi-writer scalar, membership set, or tally. Only the middle three belong in the CRDT, and the first usually does not need a merge at all because only one party writes it. Reserve a separate acknowledged command path for anything with a safety or physical bound.

Use hybrid logical clocks, not raw wall-clock time, for every register, with a node identifier tiebreaker. Add a skew guard that rejects timestamps beyond a configured tolerance. Prefer an existing library for anything beyond the primitives in this article; Automerge is a reasonable starting point for JSON-shaped twin documents because of its Rust core and offline-first design, while Yjs fits when collaborative text and its provider ecosystem matter more.

Plan the lifecycle from day one: tombstone policy, delta buffer sizing, replica retirement, and schema versioning. Run chaos tests that partition links for hours, skew clocks by minutes, duplicate and reorder deltas, and assert that all replicas converge. A property-based test that applies random operations to N replicas in random order and checks equality is cheap and catches most join-law violations.

Classify each property: single-writer, LWW, OR-Set, counter, or log.
Keep safety-bounded commands off the CRDT path.
Use HLC with node tiebreaker and a timestamp skew guard.
Keep raw telemetry out of the document; store summaries only.
Choose a tombstone strategy and a maximum offline duration.
Version the document schema and make changes additive.
Authenticate peers and authorize deltas per property.
Monitor document size, HLC drift and delta buffer depth.
Test convergence under partition, reordering and duplication.

Frequently Asked Questions

What is a CRDT in a digital twin context?

A conflict-free replicated data type is a data structure whose copies can be updated independently, including while offline, and merged deterministically with no coordination. In a twin, the property map, tags and counters are CRDT-typed so the edge and cloud replicas converge to the same state after a partition. The guarantee is strong eventual consistency: replicas that have received the same updates hold the same state. It guarantees agreement, not that the agreed value satisfies business rules.

Are CRDTs better than last-write-wins for edge twins?

LWW is itself a CRDT when implemented as a register with a total order on timestamps, so the real question is the timestamp source and the data type. Wall-clock LWW is fragile under clock skew. HLC-based LWW is safer, and OR-Sets or counters preserve concurrent updates that LWW would overwrite. Use LWW where “latest value wins” matches the meaning of the property, and richer types elsewhere.

What is the difference between state-based, operation-based and delta CRDTs?

State-based CRDTs ship full state and merge with a join, tolerating lossy links but costing bandwidth. Operation-based CRDTs ship small operations but need reliable, causally ordered, exactly-once delivery. Delta-state CRDTs, described by Almeida, Shoker and Baquero, ship small state fragments that merge with the same join, giving small messages and tolerance of unreliable channels. For intermittent edge links they are usually the best fit.

Can I use CRDTs to synchronize control commands?

Not safely on their own. CRDTs cannot enforce invariants such as bounds, mutual exclusion or exactly-once actuation, because replicas decide without seeing each other. Concurrent commands can merge into a physically invalid value. Send actuation through a single authoritative writer with acknowledgements, and use the CRDT for the replicated record of desired and reported state in low-risk properties.

How do I deal with tombstones growing forever?

Bound them by design and by process. Keep unbounded history in a log with retention instead of in the CRDT, track acknowledgements to drop tombstones once every peer has passed them, retire dead replicas explicitly, and use periodic epoch snapshots that replicas must rebase onto. Define a maximum offline duration and force a full resync beyond it, so a very old replica cannot resurrect deleted data.

Should I use Automerge or Yjs for a digital twin?

Both are network-agnostic and support offline-first use. Automerge documents are JSON-like trees with a Rust core and WebAssembly and C bindings, which suits structured twin state. Yjs offers a rich provider ecosystem for networking and persistence and is strongest for collaborative text. Neither publishes IoT-scale throughput guarantees in the documentation I reviewed, so benchmark your own document shape and update rate before committing.

CRDTs for Digital Twin Synchronization: Offline-First State Replication at the Edge