CelinQ Insights · No. 54

Two Architects, One Diagram: Hot Collaboration Mode for Enterprise Architect

A few seconds of debounce is invisible, most of the time. When two architects are actively shaping the same diagram together, CelinQ notices and tightens up.

Smart Sync's default cadence is tuned for the common case: an architect working largely alone, making a burst of related changes, pausing, and moving on, with a colleague's updates arriving in the background a few seconds after they happen. That rhythm is comfortable and almost invisible for the great majority of a working day. It stops being comfortable in one specific, recognisable situation: two architects, both actively working on the same diagram at the same time, each one waiting a few seconds longer than they would like to see what the other just did. A few seconds of debounce that nobody notices when working solo becomes a few seconds of visible lag when two people are, in effect, having a live conversation through the model. CelinQ calls this situation "hot," and it changes its own behaviour automatically the moment it detects it.

What actually happens when a diagram gets contended

Picture the scenario directly, because it is a genuinely common one rather than an exotic edge case. Two architects, Rafael and Ines, are on a call together, both looking at the same component diagram, deciding in real time how to restructure a subsystem. Rafael moves a component and draws a new connector. A moment later, working from what he just did, Ines wants to reposition an adjacent component so the diagram reads cleanly. Under the default cadence, Rafael's change debounces for a few seconds before it leaves his machine, travels to the server, and arrives on Ines's screen — a delay that, in a solo working session, would be genuinely unnoticeable, but that here means Ines is, for a few seconds, working from a version of the diagram that does not yet reflect what her colleague just did. Multiply that by however many exchanges happen in a live pairing session and the friction compounds: not a technical problem in the sense of anything going wrong, but a felt one, because the two of them are trying to move at conversational speed and the tool's ordinary rhythm was tuned for a quieter kind of work.

This is precisely the situation CelinQ's presence system is already watching for, because presence already knows, moment to moment, which diagram each connected client currently has open. Hot detection is built directly on top of that existing signal rather than as a separate mechanism: when the server's presence registry sees two or more distinct clients reporting the same current diagram, it marks that workspace as hot. No new tracking had to be invented to make this work — the information was already there, being collected for a different purpose, and Hot Collaboration is simply a second use for it.

What actually changes: cadence, not architecture

It is worth being precise about the scope of what Hot Collaboration does, because it would be easy to imagine something more dramatic than what actually happens. When a workspace goes hot, the server's response to each client's regular heartbeat carries a flag, and Smart Sync's scheduler reacts to that flag by tightening two of its three timescales. The debounce window, normally a few seconds, shortens to roughly one second, so a burst of related edits is packaged and pushed to the server sooner. The safety sync interval, normally sixty seconds, shortens to fifteen. Nothing else about the architecture changes. There is no separate "hot mode" data path, no special-case merge logic, no different rules for what counts as a conflict. Hot Collaboration is a cadence adjustment, deliberately narrow in scope, precisely because the underlying mechanisms — debounce, safety sync, deep reconciliation, Fusion's deterministic merge — already work correctly at any speed, and the only thing genuinely worth changing when contention rises is how quickly they run.

This matters because it keeps the guarantee simple to reason about. EA reads and writes never wait on the network, whether a workspace is hot or not; Hot Collaboration changes propagation frequency only, and explicitly does not touch local responsiveness in any way. An architect working inside a hot diagram feels exactly the same local editing speed they always do — clicking, dragging, typing are unaffected — and the only difference they notice, if they notice anything at all, is that their colleague's changes now tend to show up a little sooner than usual.

Why tightening the cadence is often enough on its own

Why do a shorter debounce and a faster safety sync actually help, given that the whole point of Smart Sync is preventing conflicts by shrinking the window during which two people's work can diverge undetected? The answer is that Hot Collaboration is exactly that same logic, applied more aggressively at exactly the moment it is worth the extra cost. Under the default cadence, a divergence window of a few seconds is a perfectly sensible trade-off for the ordinary case, where the odds of two people touching the same element in that window are low. Inside a genuinely hot diagram, those odds rise sharply, because by definition two or more people are actively working on the same small piece of the model at the same time — so the same window that was comfortably small for the ordinary case becomes the single largest lever available for reducing how often their work actually collides. Shortening it from a few seconds to roughly one is a proportionate response to a proportionately higher risk, not a change made for its own sake.

The practical effect, in the Rafael-and-Ines scenario, is that the gap between "Rafael moves a component" and "Ines sees it moved" shrinks from a few seconds to closer to one, and the safety sync backing that up tightens from a full minute to fifteen seconds in case anything in the fast path stumbles. Neither of them consciously experiences a mode switch. What they experience is a diagram that behaves, for as long as they are both actively in it together, noticeably more like a live shared surface than it did a moment ago — and that impression fades back to the ordinary rhythm on its own once one of them moves on and the contention that triggered it is gone.

What genuine geometry conflicts look like, and why most contention is not one

It would be a mistake to assume that two architects working on the same diagram are, most of the time, fighting over the same object. In practice the far more common pattern is two people working on different objects within one shared diagram — Rafael repositioning one component while Ines adjusts a completely different connector's routing a few centimetres away on the canvas. CelinQ's Fusion merge engine treats diagram geometry the way it treats every other kind of model fact: at the granularity of the individual object, not the whole diagram. Two architects moving and resizing different objects on the same diagram produce two changesets whose geometry facts simply do not overlap — this is the case Fusion's engineering documentation refers to with the rule code DIAGRAM_DISTINCT_OBJECT_GEOMETRY, and it merges automatically and deterministically, with both architects' layout changes present in the result, exactly as if each had made their adjustment alone. The tightened cadence of Hot Collaboration is what gets each of their changes to the other quickly; the actual combining of the two, once both arrive, is ordinary merge-atom-level Fusion work that does not need to know or care that the diagram happened to be hot.

A move-plus-resize on two different objects follows the same pattern for the same reason: a position change and a size change are distinct facts about distinct objects, so Rafael resizing one component while Ines relocates a different one nearby produces no real conflict at all, regardless of how quickly or slowly each change happened to propagate. What genuinely does conflict, and what no cadence adjustment can prevent on its own, is two architects moving the very same object to two different positions within the same short window — a real disagreement about where that one thing on the canvas should sit, which Fusion correctly declines to guess about and instead surfaces as a decision for a person to make, exactly as it would for any other same-fact collision anywhere else in the model. Hot Collaboration's tightened cadence makes this specific, narrower case rarer by shrinking the window in which it can occur, but it does not and should not try to resolve it invisibly when it does, because inventing a plausible-looking position for an object that two people genuinely disagreed about would be exactly the kind of silent guess this whole series argues against.

Targeted reconciliation: not every part of the model is equally interesting right now

There is a subtler benefit to detecting hot contention that goes beyond simply moving faster across the board. Once the server knows specifically which diagram is hot, and CelinQ's presence data tells it specifically which clients are working there, the reconciliation effort that follows can be targeted rather than generic — the parts of the model experiencing genuine contention right now are exactly where propagating changes promptly matters most, while the rest of a large repository, quiet and untouched during that same window, does not need the same urgency applied to it. This is a natural consequence of tracking presence at the diagram level in the first place, described in the presence article's discussion of granularity: knowing precisely where the contention is means the response to that contention can be precise too, rather than treating an entire large workspace as equally urgent because two people happen to be busy in one small corner of it.

Why not simply lock the diagram while it is hot?

It is a fair question, and worth answering directly rather than assuming the answer is obvious. The moment CelinQ's server detects that two people are working on the same diagram, it would be technically straightforward to respond by locking that diagram to whichever of them got there first, forcing the second to wait — reintroducing, in a narrow and automatic form, exactly the mechanism this series argues against elsewhere. The reason CelinQ does not do this is that hot contention is, in the overwhelming majority of real cases, not actually a problem that needs preventing. Rafael and Ines working on the same diagram together, in the scenario above, are not colliding by accident; they are deliberately collaborating in real time, and a lock that stopped one of them the moment the other opened the diagram would break the exact workflow that brought them there together in the first place. Locking the diagram would solve a problem neither of them has. What they actually want is for their simultaneous work to combine quickly and cleanly, which is precisely what a tightened cadence over a deterministic merge engine delivers, and precisely what a lock would prevent by forcing them to take turns instead.

The deeper reason is one this series returns to repeatedly: locking protects against a collision by forbidding concurrency outright, whether or not a genuine collision was actually about to happen. Hot Collaboration takes the opposite approach on purpose — it assumes concurrency is not merely tolerable but often exactly what the two people in the diagram actually want, and it optimises for making that concurrency work well rather than for preventing it. The cases where the two of them genuinely do touch the same object at the same moment are handled honestly, by Fusion isolating that specific fact for a decision, rather than by a lock quietly deciding in advance that neither of them was allowed to try.

Watching contention from the outside

None of this is invisible to the people responsible for a workspace as a whole. Because hot detection is built on the same presence registry that already powers the Control Plane's Clients view, an administrator can see, in real time, which diagrams across a workspace are currently experiencing genuine contention — not as a special alert requiring separate configuration, but as a natural reading of the same live client list everyone already has access to: several clients, same current diagram, at the same moment. For a team lead trying to understand why a particular part of a large model is generating an unusually high rate of Fusion decisions on a given day, this is often the first and most useful clue, because it turns an otherwise puzzling cluster of conflicts into a legible fact: a specific diagram was genuinely busy, several people were deliberately working on it together, and the small number of real conflicts that resulted are the expected residue of that busyness rather than a sign that anything is wrong with the model or the merge engine. Sync monitoring more broadly — sync lag, conflict rate, auto-merge rate across an entire workspace — is its own subject, but hot diagrams are frequently the specific, explainable source behind numbers that would otherwise look concerning in aggregate.

Cooling down: hot is a temporary state, not a switch someone has to remember to flip

Hot Collaboration is entirely automatic in both directions. Nobody declares a diagram hot, and nobody has to remember to declare it cool again afterwards. The moment fewer than two clients are reporting the same current diagram — because one architect closed it, moved to a different part of the model, or simply stepped away long enough for their presence entry to expire — the workspace stops being hot, and Smart Sync's cadence relaxes back to its defaults on its own. There is no lingering "recently hot" state and no manual reset required. This matters for the same reason presence itself needed a short TTL rather than a persistent record: a feature that stayed switched on past the moment it was actually needed would slowly become background noise, either wasting effort tightening a cadence nobody currently benefits from, or — worse — training architects to distrust the indicator because it no longer reliably reflects what is actually happening right now.

Hot Collaboration is not a mode you turn on for a pairing session. It is a property the system notices about itself, moment to moment, and lets go of just as quickly once it is no longer true.

The advisory lease option, and why it stays optional here too

Some teams, working through a genuinely difficult piece of shared diagram restructuring, would prefer a stronger signal than a tightened cadence — a way of saying, visibly and deliberately, "I am the one actively shaping this area right now, give me a moment before you restructure it too." This is the same advisory-lease concept discussed in the context of presence generally: an optional, soft, time-boxed claim that carries social weight without ever becoming a hard block, because offline editing and independent work must always remain genuinely possible, even inside a diagram that is currently hot. Hot Collaboration does not require this feature to be useful — the tightened cadence and Fusion's deterministic per-object merging already handle the overwhelming majority of contended-diagram scenarios cleanly on their own — but for the narrower case of two people deliberately co-editing one specific object in real time, an advisory lease would be a natural, still-non-blocking refinement layered on top of hot detection rather than a replacement for it. It remains, deliberately, unbuilt for now, for exactly the reason explained elsewhere in this series: getting the "advisory" part to actually stay advisory in practice is a harder design problem than the underlying signal, and it is better to ship it right than to ship it early.

The honest limits of tightening a cadence

Hot Collaboration narrows a window; it does not close it, and it would be wrong to suggest otherwise. Even at a one-second debounce and a fifteen-second safety sync, two architects moving quickly enough, or working through a connection slow enough that even a shortened window has time to matter, can still produce a genuine same-object conflict, and when they do, Fusion still has to isolate it and hand it to a person rather than guess. Tightening the cadence lowers the odds of that happening; it does not and cannot make the odds zero, because zero is not achievable without abandoning local-first editing altogether and forcing every write through a live, synchronous round trip to a shared authority — which is precisely the trade-off this whole platform, and this whole article series, argues is usually the wrong one to make.

There is also a real cost to tightening the cadence that is worth naming rather than glossing over. A one-second debounce and a fifteen-second safety sync mean more frequent network traffic and more frequent small changesets for as long as a diagram stays hot, which is a reasonable trade during an active pairing session and would be a wasteful one if it ran continuously across an entire workspace regardless of whether anyone actually needed it. This is exactly why hot detection is scoped precisely — to the specific diagram where contention is real, for exactly as long as it remains real — rather than applied as a global tightening of Smart Sync's defaults. For teams whose work genuinely requires stronger guarantees than a tightened cadence and a deterministic merge can offer, the honest answer is not to push Hot Collaboration further than its design supports, but to weigh, deliberately, whether the narrow cases that call for real exclusivity are better served by the kind of pessimistic locking this series discusses on its own terms, rather than asking an optimistic, convergence-based system to imitate one.

Return, finally, to Rafael and Ines. Their call ends after twenty minutes of genuinely productive, fast-moving joint editing, during which the diagram stayed hot the entire time and neither of them ever waited on the other for longer than the briefest, barely perceptible delay before a change appeared. Rafael closes the diagram to move on to something else; a minute later Ines does the same. The presence entries expire, the workspace quietly stops being hot, and Smart Sync settles back into its ordinary rhythm without either of them doing anything to make that happen. Nothing about the twenty minutes they spent working together needed a special mode they had to remember to enable, and nothing about the return to normal needed one they had to remember to switch off. That is the entire design goal of Hot Collaboration in one sentence: contention should be noticed and handled automatically, precisely where and for exactly as long as it is real, and invisible the rest of the time.