Real-Time Collaboration in CAD: CRDT Guide

Google Docs solved real-time text collaboration in 2006. Figma solved real-time design collaboration in 2016. CAD still struggles with it in 2026.

The problem is not engineering laziness. Text and vector graphics have mathematical properties that make concurrent editing tractable. Three-dimensional parametric geometry does not. When two engineers simultaneously modify a constraint graph that drives solid geometry, the merge semantics are genuinely hard.

This article explains why, what CRDTs offer, and how they apply to CAD specifically.

The File Locking Problem

Traditional CAD collaboration uses file locking: one engineer checks out a file, edits it, and checks it back in. Everyone else waits. This model was inherited from PDM (Product Data Management) systems designed in the 1990s when network bandwidth made real-time synchronization impractical.

File locking works but imposes severe constraints:

Sequential bottleneck. Only one person can edit a part at a time. For a complex assembly where multiple engineers need to modify different components, the lock contention becomes the dominant workflow delay.

Lock granularity mismatch. Locks typically apply to entire files (parts or assemblies). Two engineers who want to modify different features on the same part must wait for each other, even though their changes are logically independent.

Stale data. Engineers working on adjacent parts cannot see each other’s changes until files are checked in. Interface mismatches and collision problems are discovered late in the process.

Lock management overhead. Forgotten locks, crashed sessions with unreleased locks, and administrative overhead of lock management consume engineering time.

OT: Operational Transformation

Operational Transformation is the technology behind Google Docs and most real-time text editors. OT works by transforming each user’s operations against concurrent operations to produce a consistent result.

For text, OT is well-understood. If User A inserts a character at position 5 and User B deletes a character at position 3, User A’s operation must be transformed to account for the position shift caused by User B’s deletion.

For CAD, OT faces serious challenges:

Operation complexity. A text insert is a single operation with two parameters (position, character). A CAD operation (extrude a sketch profile by 10 mm along a normal) has dozens of parameters and depends on the entire upstream feature history.

Non-commutative operations. In text, most operations are approximately commutative after transformation. In CAD, the order of Boolean operations matters: (A union B) difference C is not the same as (A difference C) union B in general.

Cascading failures. A transformed text operation might produce an unexpected character position. A transformed CAD operation might produce invalid geometry: self-intersecting surfaces, zero-thickness features, or topological impossibilities. The failure mode is fundamentally more severe.

CRDTs: Conflict-Free Replicated Data Types

CRDTs take a different approach. Instead of transforming operations after the fact, CRDTs design the data structure itself so that concurrent modifications always converge to the same state, regardless of the order in which they are applied.

A CRDT has three properties:

1. Commutativity. Applying operation A then B gives the same result as B then A.
2. Associativity. Grouping operations differently does not change the result.
3. Idempotency. Applying the same operation twice has no additional effect.

These properties guarantee that every replica of the data converges to the same state without coordination, even in the presence of network partitions and message reordering.

CRDT Variants Relevant to CAD

G-Counter / PN-Counter. Simple counters that support increment and decrement. Useful for tracking version numbers and operation counts in the parametric history.

LWW-Register (Last-Writer-Wins). A register that resolves concurrent writes by timestamp. Suitable for scalar parameter values where the latest edit should win.

MV-Register (Multi-Value). A register that preserves all concurrent values and presents them to the user for manual resolution. Suitable for parameters where automatic resolution would produce surprising results.

OR-Set (Observed-Remove Set). A set that supports concurrent add and remove operations. Useful for the set of features in a model: two users can independently add and remove features without conflict.

RGA (Replicated Growable Array). An ordered sequence that supports concurrent inserts and deletes. Applicable to ordered feature lists and constraint sets.

Geometric Collaboration Challenges

Applying CRDTs to CAD requires mapping geometric operations onto CRDT-compatible data structures. This is where the real difficulty lies.

Challenge 1: Parametric Dependency Graphs

A parametric CAD model is a directed acyclic graph (DAG) where features depend on earlier features. A fillet depends on the edge it rounds, which depends on the extrusion that created it, which depends on the sketch that defines it.

When two users concurrently modify features in the same dependency chain, the merge must:

• Preserve the DAG structure (no cycles)
• Respect dependency ordering
• Produce valid geometry at every intermediate node

This is more constrained than merging a text document or a vector drawing.

Challenge 2: Geometric Validity

Not all combinations of parametric operations produce valid geometry. Two independently valid features might produce invalid geometry when combined. A pocket that is valid on the original body might extend outside the body after a concurrent dimension change shrinks the body.

CRDTs guarantee convergence of the data structure. They do not guarantee that the converged state is geometrically valid. Geometric validation must happen after merge, and invalid states must be reported to users for resolution.

Challenge 3: Semantic Intent

When User A changes a fillet radius from 3 mm to 5 mm and User B changes it from 3 mm to 2 mm, what should the merged result be? LWW-Register picks the latest timestamp, but both users might consider their change important. The “right” answer depends on engineering intent that the CRDT cannot infer.

Challenge 4: Continuous vs Discrete Operations

Some CAD operations are continuous (changing a dimension from 10 to 10.5 mm) and others are discrete (adding or deleting a feature). Continuous operations at high frequency (dragging a dimension) generate many updates that must be efficiently compressed and transmitted. Discrete operations are infrequent but structurally significant.

CRDT Architecture for CAD

A practical CRDT-based CAD collaboration system layers multiple CRDT types:

Layer 1: Feature Graph (OR-Set + Causal Ordering)

The set of features in the model is an OR-Set CRDT. Users can concurrently add and remove features. The OR-Set semantics ensure that concurrent add-remove conflicts resolve to the “add wins” policy (a standard choice in collaborative systems).

Feature ordering within the dependency DAG is maintained by causal timestamps (vector clocks or hybrid logical clocks) that establish happens-before relationships.

Layer 2: Parameter Values (LWW-Register or MV-Register)

Each parameter (dimension value, material property, constraint tolerance) is an individual CRDT register. For most parameters, LWW semantics (last write wins) produce acceptable results. For critical parameters where concurrent modifications indicate a design conflict, MV-Register semantics preserve both values and flag the conflict for manual resolution.

Layer 3: Sketch Geometry (RGA for point sequences + LWW for coordinates)

Sketch entities (lines, arcs, splines) are ordered sequences of control points. The sequence structure is an RGA for insertions/deletions of control points. Individual coordinate values are LWW-Registers.

Layer 4: Constraint Graph (OR-Set of constraints)

Geometric constraints (coincident, parallel, tangent, dimensional) form a set that uses OR-Set semantics. Concurrent additions of redundant constraints are resolved by the constraint solver detecting over-determination and reporting it.

Deterministic Merging

For the merged parametric model to be identical on every user’s machine, the geometry evaluation must be deterministic. Given the same feature graph and parameter values, every client must compute the exact same geometry.

This is harder than it sounds:

Floating-point non-determinism. Different CPU architectures, compiler optimizations, and instruction ordering can produce slightly different floating-point results. These differences accumulate through a long feature chain. Solutions include using deterministic math libraries, canonicalizing computation order, or accepting and bounding divergence.

Solver non-determinism. Constraint solvers and tessellation algorithms may have multiple valid solutions. A 2D constraint system might have two valid configurations (a quadrilateral can be convex or concave). The solver must use deterministic tie-breaking rules.

Hash-based verification. After merge, each client computes a hash of the geometric state. If hashes diverge, the system detects inconsistency and triggers a full resynchronization from a canonical source.

Chertalo’s implicit geometry kernel addresses deterministic merging through its constraint graph architecture. The parametric model is a DAG of field operations, each with deterministic evaluation semantics. The CRDT layer synchronizes the graph structure and parameter values, and the local kernel evaluates geometry identically on every client because SDF evaluation is purely functional: the same inputs always produce the same field values.

Current State and Limitations

Real-time CRDT-based CAD collaboration is emerging but not yet mature. Onshape’s server-mediated approach avoids the distributed systems complexity by keeping a single authoritative model on the server. Figma-style CRDTs work for 2D vector editing but have not been demonstrated at the complexity level of 3D parametric CAD.

The open problems are:

• Conflict presentation. When geometric conflicts arise, how do you present them to users in an understandable way? Text diff is well-understood. Geometry diff is not.
• Undo in concurrent editing. Undoing your own operation after other users have built on it requires careful CRDT design to avoid cascading invalidation.
• Performance at scale. A complex parametric model with thousands of features generates a large CRDT state. Synchronization traffic and merge computation must remain interactive.

Why It Matters

Engineering teams are distributed. Supply chains are global. The file-locking model that worked when a team of five sat in the same office does not work when the team spans continents and time zones.

Real-time collaboration in CAD is not a luxury feature. It is an infrastructure requirement for modern product development. CRDTs provide the mathematical foundation for making it work without a central server bottleneck. The engineering challenge is mapping the rich semantics of parametric geometry onto this foundation.

The first CAD platform that solves this well will have the same competitive advantage in engineering collaboration that Google Docs created in document collaboration. The race is on.