CelinQ Insights · No. 12

Keeping a large model responsive as the team and the model grow

Why shared repositories slow down under load, and why local editing does not.

Every architecture team that succeeds eventually creates the conditions for its own frustration. A model that is useful attracts more content, more contributors, and more dependence, and each of those is a good sign. But together they change the physics of the repository. The model that opened instantly and saved without a thought when it was small and had two editors becomes, a few years and several thousand elements later, a thing people brace themselves before opening. Diagrams take a moment to render. Saves pause. A search that used to be immediate now has a visible wait. And when several architects are working at once during a busy period, the whole thing seems to thicken, as if the repository were wading through something. The team has not done anything wrong. They have simply grown, and the way they share the model does not scale with them.

The reason this feels so unfair is that the slowdown arrives exactly when the model has become valuable enough to be worth the slowdown. Nobody minds a sluggish repository that nobody relies on. The pain is proportional to the model's importance, because importance is what drives the size and the concurrency that cause the pain. So it is worth understanding precisely why shared repositories slow down under load, because the mechanism is not mysterious and the cure is not "buy a bigger server", which is where most teams instinctively reach and where most teams are disappointed.

Where the time actually goes

When several architects share a single repository over the network, almost every meaningful operation involves a conversation with a central store that is simultaneously trying to have the same conversation with everyone else. Opening a large diagram, expanding a busy part of the model tree, running a search, saving a batch of changes — each of these is a request that travels to the shared store, is serviced there in contention with everyone else's requests, and travels back. Individually these round trips are small. In aggregate, under concurrency, they are the whole problem, because the shared store is a single point through which all the work is funnelled, and a single point has a finite throughput no matter how much hardware sits behind it.

The situation is made worse by the fact that architectural work is bursty and interactive rather than steady and batched. An architect does not send the repository one large, efficient request; they send hundreds of small, latency-sensitive ones as they navigate, adjust, reconsider, and refine. Interactive work is exquisitely sensitive to latency, because the human is waiting, watching the cursor, and every fraction of a second of delay is felt directly. When the store is under contention, that latency rises for everyone at once, and it rises fastest precisely during the collaborative bursts — the workshop, the deadline, the review push — when responsiveness matters most and when the largest number of people are competing for the same finite throughput.

There is a compounding effect from model size layered on top of the concurrency effect. As the model grows, the individual operations themselves get heavier: there is more to search, more to load, more relationships to resolve when a diagram is opened. So the team is squeezed from two directions at once. Each operation costs more because the model is larger, and each operation waits longer because more people are contending for the shared store. These two curves multiply rather than add, which is why the degradation so often feels like it arrives suddenly. For a long time the model is small enough and the team is small enough that neither factor bites, and then both cross their thresholds around the same period of growth, and the repository seems to fall off a cliff that was in fact a slope all along.

Why more hardware disappoints

The natural response to a slow shared repository is to give it more resources — a faster database server, more memory, a better network link. This helps, and it is not wrong to do, but it disappoints relative to expectations because it treats a structural problem as a capacity problem. The structural issue is that all the interactive latency-sensitive work is being routed through a single contended point and across a network. A bigger point is still a single point, and a faster network still has a round trip. You can raise the ceiling, and the team enjoys a period of relief, but the two multiplying curves are still climbing, and they will reach the new ceiling too, usually sooner than anyone expects because the team has kept growing in the meantime.

More fundamentally, no amount of central capacity removes the network round trip from interactive editing. If the authoritative model lives centrally and the architect's every navigation and adjustment consults it, then the architect's experience is bounded below by the latency of reaching the centre, no matter how fast the centre is once reached. For a team spread across offices, working from home, or occasionally working somewhere with a poor connection, this floor can be high and, worse, unpredictable, because the network is not under anyone's control. The experience of the model becomes hostage to the quality of the link on any given day, which is a deeply unpleasant way to work and one that hardware upgrades to the server cannot touch, because the problem is not at the server.

Moving the interactive work off the shared path

The way out is to notice that the thing which must be responsive — the architect's moment-to-moment editing — does not actually need to consult a shared store at all. It only needs the model. And the model can live right next to the architect, on their own machine, where there is no contention and no network between the person and their work. This is the premise CelinQ is built on. Each architect edits a local repository at full speed, and that speed is genuinely local speed: opening a diagram, searching, navigating, and saving all happen against a store on the architect's own machine, with no round trip to a shared point and no contention with anyone else, online or offline.

The sharing does not disappear; it moves off the interactive path. A background companion syncs each save with a shared workspace on a server the organisation runs itself. The key word is background. Synchronisation happens alongside the architect's work rather than in front of it, so the cost of sharing is no longer paid as latency on every interactive operation. The architect is not waiting for the shared workspace when they open a diagram, because opening a diagram never touches the shared workspace. It touches the local repository. The shared workspace finds out about the change afterward, through the companion, without the architect ever having to wait for that to complete.

This single architectural choice is what breaks the multiplying curves apart. Model size still makes individual operations heavier, because a larger model is a larger model wherever it lives — but now those heavier operations run locally, at full local speed, without the added burden of contention. And concurrency no longer degrades interactive responsiveness at all, because the architects are not contending for a shared store while they edit; they are each working against their own. Ten architects editing simultaneously is not ten times the load on a shared point during editing. It is ten independent local sessions, plus background synchronisation that does not block any of them. The busy workshop that used to be the worst-performing moment becomes, for interactive purposes, indistinguishable from a quiet afternoon, because the number of concurrent editors has stopped being a factor in how fast any one of them can work.

What the background companion has to get right

Moving synchronisation into the background only helps if the synchronisation is actually correct, because a fast local experience is worthless if reconciling everyone's local work into the shared model produces chaos. This is where the merge engine does the heavy lifting. CelinQ Fusion performs a deterministic, reproducible three-way merge at the granularity of individual model facts. When two architects have, in their separate local repositories, changed different things, both changes are combined into the shared workspace without either being lost. When they have genuinely changed the same thing incompatibly, the conflict is isolated and made explicit rather than resolved by whichever save arrived last. Because the merge operates on individual model facts rather than on whole files or whole diagrams, most parallel work does not conflict at all, and the synchronisation is quiet precisely when a coarser approach would be loudest.

Determinism matters for performance in a way that is easy to overlook. A merge that is reproducible does not require human adjudication except where there is a real, isolated conflict, so the background synchronisation does not constantly interrupt people to resolve things a machine can resolve correctly on its own. The interruptions are reserved for genuine disagreements, which are rare relative to the total volume of change, so the companion stays in the background where it belongs and does not leak back onto the interactive path as a stream of prompts. The team gets local speed for editing and a coherent shared model for collaboration, without the usual trade-off in which fast local work produces a merge mess that someone has to clean up by hand.

Smart Sync tunes the cadence of this background activity so that it fits the situation rather than running at one fixed rhythm regardless. The synchronisation adapts, which means it can be attentive when there is active collaboration to reconcile and restrained when there is not, and in either case it stays out of the way of the person editing. The architect does not manage it and mostly does not notice it, which is the correct relationship to have with something that is meant to be invisible infrastructure. The moment synchronisation demands attention during ordinary work, it has failed at its job, and Smart Sync exists precisely to keep it from doing so.

Offline as a consequence, not a feature

One of the more telling properties of this arrangement is that working offline stops being a special mode and becomes simply what happens when the network is not there. Because the architect's editing is against a local repository, losing the connection does not stop the work; it only pauses the background synchronisation, which resumes and reconciles when the connection returns, through the same deterministic merge. This is not a feature that had to be added. It is a direct consequence of having moved the interactive work off the shared path. Anything that is genuinely local is, by definition, available offline, because there is nothing remote it depends on to function moment to moment.

The significance of this for performance is that it removes the network as a variable in the daily experience of the model. A team working this way does not have good days and bad days depending on the state of the link, because the link is not on the critical path of editing. The occasional poor connection, the trip to a site with no reliable network, the home office with a flaky line — none of these degrade the editing experience, because the editing was never reaching across the network in the first place. Responsiveness becomes a property of the architect's own machine, which is stable and knowable, rather than a property of the network and the shared store, which are neither.

Being honest about the trade-offs

It would be dishonest to present this as free. Local-first working means each architect's machine holds a repository and does the work of editing it, so there is a real, if modest, requirement on the individual workstation — the kind of machine an architect already has, but a genuine requirement nonetheless. And synchronisation in the background is not the same as instantaneous universal visibility; there is a short interval between one architect's save and its appearance in everyone else's world, because the change has to flow through the companion and the merge. For the overwhelming majority of architectural work this interval is invisible and irrelevant, but it is honest to acknowledge that "local-first with background sync" is a different consistency model from "one shared database everyone edits live", and a team should understand which one they are choosing.

The shared workspace itself still runs somewhere and still has to be maintained, backed up, and given enough resources to accept synchronisation from the whole team. The difference is that it is no longer on the interactive path, so its performance requirements are far gentler: it must be able to receive and reconcile changes, not to service every navigation and search from every architect in real time. That is a much easier thing to provision for, and it scales far more gracefully, because accepting a stream of well-formed changes in the background is a fundamentally lighter task than being the live, contended backend for everyone's interactive editing at once. Storage can be SQLite or PostgreSQL depending on scale, and the whole arrangement can stay under the organisation's control, which matters for the many teams whose constraints are as much about sovereignty as about speed.

None of this makes a large model small. A model with many thousands of elements is a large thing to work with, and CelinQ does not pretend otherwise; the operations on it are heavier than the operations on a small model, and always will be. What changes is that the weight is borne locally, at full speed, without contention and without a network round trip, so the model's growth stops being compounded by the team's growth. The two curves that used to multiply are pulled apart, and the repository stops falling off the cliff that its own success was building.

What responsiveness does to the quality of the work

It is easy to treat performance as a comfort issue — a matter of whether architects are annoyed — and to rank it below correctness and governance as a result. That underrates it, because responsiveness changes not just how pleasant the work is but what work actually gets done. A repository that responds instantly invites a particular kind of activity: the small, frequent, exploratory adjustment. An architect will try a rearrangement, look at it, dislike it, and undo it, all in a few seconds, because the cost of the experiment is trivial. This is how good models get built, through many cheap iterations rather than a few expensive ones, and it depends entirely on each iteration being cheap.

When the repository is slow, this exploratory rhythm dies, and it dies quietly, without anyone deciding to abandon it. If every adjustment carries a visible wait, the architect stops making adjustments they are not already sure of. The tentative reorganisation that might have improved the model never gets tried, because trying it and reverting it now costs real time and real patience. The work shifts from exploration to commitment: people plan the change in their heads, or on paper, and then execute it once, because the repository has made iteration too expensive to indulge. The model still gets built, but it gets built more conservatively and less well, and nobody can point to the moment the quality was lost, because it was lost as an accumulation of experiments not run rather than as a single visible failure.

The same dynamic governs whether people keep the model current at all, which is ultimately a larger question than the quality of any single edit. A model earns its keep only if it reflects reality, and it reflects reality only if people update it as reality changes — which they will do routinely if updating is quick and reluctantly if it is slow. A sluggish repository quietly teaches the team to batch their updates, to let corrections pile up until there is enough of them to justify the pain of a session, and a model updated in occasional batches is a model that is wrong for most of the time between them. The slowness does not merely annoy; it introduces a lag between the architecture and its record, and that lag is the difference between a model people trust on sight and one they feel obliged to double-check against reality before relying on. Responsiveness, in this light, is not a luxury layered on top of a working model. It is part of what keeps the model working, because it keeps the friction of staying current low enough that staying current remains the default rather than the exception.

Local-first editing restores the cheap iteration by making every operation respond at the speed of the architect's own machine, which is the speed at which exploratory work is possible. The architect can try the rearrangement, dislike it, and undo it in the same few seconds they always could, regardless of how large the model has grown or how many colleagues are working at the same moment, because none of that touches the local repository they are editing against. The background companion carries the finished thinking out to the shared workspace afterward, but the thinking itself happens at full local speed. This is the part of the performance argument that matters most and is discussed least: keeping the model responsive is not about sparing architects an annoyance, it is about preserving the working rhythm that produces good architecture in the first place. A model that is painful to edit becomes a model that is edited defensively, and defensive editing produces defensive architecture — which is the real, if invisible, cost of letting a shared repository slow down as the team and the model grow.

A grounded takeaway

If a shared repository is getting slower as the team and the model grow, the instinct to blame the hardware and buy more of it is understandable but usually misdirected. The slowdown is structural: interactive, latency-sensitive work is being funnelled through a single contended store across a network, and both the size of the model and the number of concurrent editors push on that structure at once. More hardware raises the ceiling without changing the structure, which is why the relief it brings is temporary and the disappointment reliable.

The durable answer is to take the interactive work off the shared path entirely, which is what local-first editing does. Each architect works at full local speed against their own repository, online or offline, while a background companion keeps a shared workspace synchronised through a deterministic, reproducible merge that keeps parallel work and isolates only genuine conflicts. Concurrency stops degrading responsiveness because there is nothing shared to contend for during editing, and network quality stops governing the daily experience because editing never reaches across the network. The model can keep growing and the team can keep growing, and the thing that used to get worse with every success instead stays responsive, because responsiveness was moved to the one place that does not get more crowded as the organisation scales — the machine in front of each architect. That is not a trick of tuning or a bet on bigger servers. It is a different arrangement of where the work happens, and it is the arrangement that stays fast when everything else about the model is getting larger.