Character-level merging and block-level locking each carry their own cost

What it is

The two mainstream routes for handling concurrent editing are, at bottom, a choice about granularity. Character-level merging — operational transformation and CRDTs are the canonical machinery — fuses concurrent edits at extremely fine grain: two people type at once, neither is blocked, and the system interleaves their operations at the character level. Block-level locking takes the opposite extreme: a paragraph, a cell, or an object belongs to one editor at a time, and everyone else waits. The former buys nearly unrestricted parallelism at the price of handing "what the fused result means" to an algorithm; the latter buys semantic integrity at the price of serializing the work. These are not old and new — they are two goods with different cost structures.

Why it happens

Granularity governs two probabilities. The first is collision probability: the finer the merge unit, the less likely two edits land in the same unit. Two people typing in one paragraph rarely touch the same character, so character-level logic lets most edits fuse freely, while block-level logic makes the whole paragraph mutually exclusive. The second is fusion quality: the finer the unit, the more often automatic fusion produces something syntactically valid but semantically absurd — two people each rewrite half a sentence, and character-level merge assembles a sentence neither of them wrote. It converges, but it is what nobody wanted. Locking eliminates the problem at the root: if only one person can write at a time, there is nothing to fuse, only waiting. The cost curves therefore cross. Merge cost rises with semantic sensitivity (prose forgives, code and formulas do not); lock cost rises with region size and hold time (the coarser and longer-held the lock, the more people it blocks).

Studying it

• Paradigm: at the algorithm level, the convergence conditions of operational transformation and the strong eventual consistency of CRDTs are formally specified and proven, so routes can be compared as theorems; at the system level, deployment logs let one compare lock-based and merge-based editors on wait-event rates, throughput, and post-merge immediate re-edits; at the user level, granularity is manipulated in controlled studies, measuring blockage rate, perceived interruption, and ratings of the merged text.
• Variables: merge/lock granularity, artifact type (prose, code, spreadsheets), group size as independents; perceived-conflict frequency, lock wait time, and semantic acceptability of merged output as dependents.
• Methodological caveat: formal proofs cover only the convergence property. Whether a granularity fits is ultimately a human judgment about the merged result's meaning, which cannot be automated; substituting machine-computable metrics (collision rate, wait duration) for semantic-quality ratings systematically overstates fine-grained merging.

Where it stops holding

For live co-authoring of prose — meeting minutes, shared documents — character-level merging is the de facto default, because collisions are rare, prose is forgiving, and being blocked costs more than the occasional mangled sentence. Code and spreadsheet formulas are the opposite: globally semantics-sensitive artifacts where one line's meaning depends on the whole file, and character-level interleaving can produce code that does not compile or logic that is wrong — which is why code collaboration still uses line/block-level three-way merge with human confirmation. Locking fits contexts where the region is naturally exclusive — while I rewrite this paragraph, nobody else really should be in it — but the lock boundary must align with the semantic boundary: locking the whole document to protect one paragraph bars everyone from everything. There is no globally optimal granularity, only a fit between granularity, artifact type, and conflict density.

Applying it

• Choose granularity by artifact semantics: fine-grained automatic merging for prose and free canvases; line/block granularity with explicit conflict resolution for code, formulas, and structured data.
• In locking schemes, shrink the lock to the smallest meaningful exclusive unit and add timeout-based release so one idle editor cannot hold a region hostage.
• Where locking and merging coexist in one system (say, locked cells plus merged free text), state explicitly which situations take which route — never make users guess.
• Verification: track two signals — per-person wait-for-lock events (too many means locks are too coarse) and re-edits to the same region within ten seconds of a merge (too many means automatic fusion output is being rejected).

Related

• Same group: V3.01.1 Concurrent editing of the same region requires a merge strategy · V3.01.3 Merge outcomes must be visible to users
• Nearby: V3.02 Presenting and Preserving Conflicts · V3.04 Following and Viewport Sync
• Search terms: lock granularity · operational transformation · CRDT · three-way merge