CelinQ Insights · No. 36

Why "Optimised for WAN" Is Different from "Independent of WAN"

Making a remote repository faster over distance and removing the network from the ordinary editing loop are two different engineering strategies, and vendors rarely say which one they mean.

Somewhere in most procurement conversations about a distributed Enterprise Architect deployment, a phrase gets used that sounds reassuring and means almost nothing on its own: the product is "optimised for WAN." It is the kind of claim that closes a line of questioning rather than opening one, because it sounds like the problem has already been solved by someone else, on your behalf, in advance. The trouble is that "optimised for WAN" and "independent of WAN" describe two genuinely different architectural strategies, aimed at two different failure modes, and a repository can be thoroughly optimised for wide-area access while still being completely dependent on that wide-area link staying up, staying fast, and staying within reach. Knowing which one you are being sold is not a pedantic distinction. It changes what happens on the afternoon the link degrades, and it changes what a branch office in a different country actually experiences when someone opens a diagram.

Two claims that sound like one

Optimising a centrally hosted repository for wide-area access is a real and respectable engineering discipline. It means reducing the number of round trips a given operation needs, compressing what goes over the wire, caching frequently read structures closer to the client, batching small requests into larger ones, and generally squeezing as much latency as possible out of every interaction that still, fundamentally, has to reach a server somewhere else before it can complete. Pro Cloud Server and similar centrally hosted arrangements do real work here, and that work is not cosmetic. A well-tuned remote repository over a well-provisioned network can feel genuinely responsive, and dismissing that as marketing would be unfair to the engineering involved.

What optimisation of this kind does not do, by construction, is change the shape of the dependency. Every operation still has to ask the server something, wait for an answer, and only then proceed. The improvement is in how quickly that round trip completes and how few of them a given action needs, not in whether the round trip is required at all. This is the crucial distinction, and it is exactly the one that gets lost when a sales conversation reaches for "optimised for WAN" as a synonym for "this problem is solved." A system that is optimised for WAN is still, definitionally, a system that runs its editing loop across the WAN. It has simply made that crossing as cheap as it reasonably can. Independence from the WAN is a different proposition entirely: it means the editing loop does not cross the network at all during normal work, so there is nothing left there to optimise, because there is nothing there to wait for.

Neither strategy is wrong. They solve different problems for different organisations, and it is worth being honest that centralising the repository buys something local-first replication does not — a single authoritative store with no reconciliation step, which is a genuinely simpler mental model for some teams and some governance regimes. The point of this article is not to declare one approach superior in the abstract. It is to insist that the two claims be told apart, because a reader evaluating tools for a distributed architecture practice deserves to know which promise is actually being made before they build a deployment plan around it.

What "optimised" actually optimises

It helps to be concrete about where optimisation effort typically goes in a centrally served architecture. Protocol-level improvements reduce the size and number of messages exchanged for a given user action — fetching a package's contents in fewer requests, for instance, or sending only the fields a dialog actually needs rather than an entire object graph. Server-side caching keeps hot data close to the point of service so that a second read of the same structure does not repeat the full cost of the first. Client-side caching does something similar in the other direction, holding recently seen data locally so that redundant reads never leave the machine at all. Connection reuse and multiplexing avoid the overhead of renegotiating a connection for every small interaction. All of this is legitimate, all of it helps, and all of it is worth asking a vendor about directly rather than accepting the word "optimised" as a black box.

But every one of these techniques operates within the same underlying assumption: that the authoritative copy of the model lives somewhere else, and that the working session is, at bottom, a long conversation with that somewhere else. Optimisation makes that conversation faster and quieter. It does not end it. Open a diagram with sixty objects on a network that has been optimised well, and the wait is shorter than it would be without the optimisation. Open the same diagram on a network link that has degraded — a saturated VPN, a satellite connection at a remote site, a mobile hotspot standing in for a broken leased line — and the optimisation has less and less to work with, because there is a floor under how fast a round trip to another continent can possibly be, and no amount of caching removes the trips that genuinely need fresh data. Our earlier piece on Enterprise Architect over a VPN goes into what that degradation actually looks like from the architect's chair, and it is worth reading alongside this one, because it describes precisely the condition that WAN optimisation is designed to soften without ever being able to eliminate.

What still depends on the server in CelinQ, and what does not

CelinQ takes the other branch of the fork: instead of optimising the conversation with a remote store, it removes the conversation from the part of the day where speed actually matters. Each architect works against a local Enterprise Architect repository on their own machine, and every ordinary editing action — opening a package, reading an element's properties, drawing a connector, saving a diagram, running a search across the local model — resolves entirely against local storage. None of it asks a server anything. There is no round trip to wait on because there is no round trip in that path at all, regardless of what the network happens to be doing at that moment.

That does not mean the server has become irrelevant, and it would be dishonest to imply otherwise. The server still matters, precisely and specifically, for a smaller set of things: receiving the changes an architect has made so they can reach everyone else's local repository, running the deterministic reconciliation that keeps everyone's copy converging on the same model, holding the canonical revision history that the whole workspace can be audited against, and enforcing who is allowed to do what through workspace roles and token authentication. A background agent, CelinQ Connect, is the thing that actually talks to the server — over a gRPC and protobuf sync protocol, with a REST API and a web-based Control Plane console for the operational side — and it does that talking asynchronously, on its own schedule, decoupled from whatever the architect is doing inside Enterprise Architect at that instant. The distinction is not "does the server matter" but "when does the server's availability decide whether you can work." In a centrally served repository, the answer is constantly, every click. In CelinQ, the answer is: not during editing, and only in the sense that reconciliation and visibility to colleagues eventually need it. That difference in what depends on the network and what genuinely does not is the whole of what "independent of WAN" is claiming, and it is worth demanding that precision from any vendor making a similar claim, ours included. Our piece on what changes when the repository lives beside the user goes deeper into the mechanics of that split.

The question worth asking any WAN-collaboration vendor is not "how fast is it" but "when does your product's availability decide whether I can work." Optimisation changes the first answer. Only removing the dependency changes the second.

A round trip, reasoned through

It is worth walking through what a single, unoptimised round trip actually costs, not as a measured result but as an exercise anyone can run with a stopwatch and a test network of their own. Consider a round trip of 150 milliseconds — a plausible figure for a connection between, say, a branch office in one region and a data centre in another, well within the range that ordinary corporate WAN links and VPN tunnels produce under realistic conditions, and nothing exotic or worst-case about it. On a centrally served repository, every dialog open, every property read, every save is at minimum one such round trip, and most meaningful operations need several — a lookup, a permission check, the actual read or write, perhaps a follow-up refresh. If an operation needs four round trips or a diagram open needs a dozen small reads to populate what is on screen, the arithmetic multiplies quickly, and it multiplies again across every element an architect touches in a working session, and again across every architect on the team doing the same thing simultaneously.

None of that is a claim about what any particular product measures in practice; it is simply what a round trip of that length implies once you multiply it by how many of them an operation needs, and it is precisely the kind of calculation a reader should be doing themselves rather than accepting a vendor's adjective for. On a local-first repository, that same 150 millisecond figure becomes irrelevant to the editing session, because the editing session never crosses that link. The number does not vanish from the world — it still governs how quickly a saved change becomes visible to a colleague on the other side of it — but it moves from something you pay dozens of times an hour, silently, on every click, to something you pay once, in the background, on a cadence the system controls rather than one dictated by every individual interaction. That relocation of where latency lands is the entire architectural argument, and it is worth stating plainly rather than dressed in adjectives.

When the network disappears entirely

Optimisation and independence diverge most sharply not at high latency but at zero connectivity, because an optimised remote connection is still, in the end, a connection, and connections fail. A satellite link drops during a storm. A site's internet goes down for an afternoon while a provider does maintenance nobody was told about. A VPN concentrator falls over and takes every remote session with it. In a centrally served architecture, no amount of prior optimisation changes what happens next: the repository becomes unreachable, and unreachable means unusable, however elegant the protocol was while the link was up. The best a well-optimised centrally served system can do during an outage is fail gracefully and reconnect quickly once the network returns; it cannot let you keep working through the gap, because there is nothing local to work against.

A local-first repository does not experience the same outage as an outage in the same sense at all. The architect's own copy is complete and genuinely theirs, so editing continues exactly as before — the same speed, the same responsiveness, the same tool. What changes is invisible to the person doing the modelling work: CelinQ Connect's durable offline queue holds every change locally, in order, and simply waits. It does not need special handling to survive this; the queue is built to tolerate exactly this condition, along with the duplicate-delivery risk that comes from a connection dropping mid-transmission and a client retrying. When the link returns, the queued changes replay against the server, and the same deterministic reconciliation that handles two people editing at the same moment handles two people who were editing across an outage — because from the reconciliation engine's point of view, an offline period and a network delay are the same kind of gap, just longer. This is one of the places where the earlier article on working offline in this series and the WAN question converge: an outage is simply the limiting case of high latency, stretched until the round trip never completes at all, and a design that already does not depend on the round trip completing handles that limiting case for free.

Burst synchronisation and the moment everyone comes back

The interesting operational question is not what happens during the outage but what happens the instant it ends, because that is where a design that merely tolerates disconnection can still fall over even if it survived the disconnection itself. If an entire office has been working offline for a morning and the link returns all at once, every queued client tries to reconcile at roughly the same moment, and a naive implementation could turn a graceful recovery into a thundering-herd problem — a burst of simultaneous synchronisation traffic that swamps the very link that just came back, or a server that has to process a pile-up of changesets that all arrived within the same few seconds.

CelinQ's synchronisation cadence is built around exactly this kind of variability rather than a fixed, uniform schedule. Smart Sync layers an event-driven fast path with a short debounce after an edit — a few seconds under normal conditions — against a one-minute safety synchronisation that catches anything the fast path missed, and a five-minute deep reconciliation that compares the whole repository against its last known state to recover from any drift at all. Those defaults exist for the ordinary working day, but the same layered structure is what absorbs a burst: rather than every client racing to push everything the instant a connection is detected, the fast path and the safety net together spread the reconciliation load out over the seconds and minutes that follow reconnection, and the deterministic merge pipeline on the server processes each changeset against the causal history it actually diverged from, not against a snapshot taken under load. Our dedicated article on Smart Sync covers the full mechanism; the point relevant here is that burst recovery after an outage runs on the same cadence logic that governs an ordinary Tuesday, just applied to a larger backlog.

Geo-distributed teams and the asymmetry nobody mentions

Distance is rarely symmetric across a real organisation, and this is where the WAN-optimisation strategy runs into a structural limit that no amount of tuning removes. A team with architects in three or four countries, connecting to one centrally hosted repository, does not have one latency figure to optimise for. The person nearest the server gets an excellent experience; the person on the far side of an ocean gets a materially worse one, however well the protocol is tuned, because the underlying physics of the round trip does not care how good the compression is. Optimisation can narrow that gap. It cannot close it, because the gap is a function of geography and the speed of light in fibre, not of software.

A local-first architecture removes that asymmetry from the part of the day where it hurts, because every architect's editing experience is governed by their own machine, not by their distance from a data centre. The person in the country furthest from wherever the CelinQ Server happens to be hosted gets exactly the same responsiveness inside Enterprise Architect as the person sitting next to it, because neither of them is editing against the server at all. What distance still governs is the same thing outages govern: how promptly a saved change becomes visible to a colleague elsewhere, and that is a synchronisation-cadence question rather than an editing-experience one. For a genuinely geo-distributed practice — the kind of organisation this series keeps returning to, with public-sector or multinational clients spread across offices that were never going to share a low-latency network link — that reframing is not a minor convenience. It is the difference between a tool that has a "good region" and a "bad region" and one that does not.

How you would actually measure any of this

Everything above is architectural reasoning, not a result, and it is worth being explicit about the difference, because the WAN-performance space is full of confident adjectives and short on published methodology. Anyone evaluating a claim about WAN behaviour — CelinQ's included — should ask for the same things: what hardware and repository size the test used, what Enterprise Architect version, what synthetic latency was applied and how it was simulated, whether the numbers separate an initial clone or first sync from the steady-state incremental behaviour that dominates most working days, and whether the results report a median alongside a worst-case tail rather than a single flattering average. A single number without those details tells you almost nothing, because a fast median with an ugly P95 describes a tool that is pleasant until, unpredictably, it is not.

The methodology that matters is one that runs the same operations — element creation, a rename, opening a diagram, a search across a package — at a sequence of simulated round-trip times, twenty, fifty, a hundred, two hundred milliseconds and beyond, against both a centrally served repository and a local-first one, and reports what actually happened at each point rather than asserting a conclusion. That is a benchmarking exercise, not a one-line claim, and it deserves its own space rather than a paragraph here; our companion piece on how to benchmark Enterprise Architect performance objectively lays out exactly that methodology in full, including why initial clone and incremental sync have to be measured and reported separately rather than blended into one figure. The discipline that matters most, whichever product a reader ends up choosing, is refusing to accept a performance claim that will not show its working.

What replication actually costs

None of this is free, and an article that pretended otherwise would not be worth trusting. Removing the network from the editing loop does not remove complexity from the system; it relocates it, from a place where it was at least visible and synchronous — you clicked, you waited, you knew exactly what you were paying for — to a place that is asynchronous and, by its nature, less immediately visible: reconciliation. The moment two architects can both edit the same model at the same time without either of them waiting for the other, someone has to decide what happens when their changes genuinely collide, and that decision has to be made correctly, deterministically, and in a way that never silently discards anyone's work. That is a real engineering surface, not a footnote. CelinQ's answer to it is the Fusion merge engine, tested against a hundred thousand operations from five concurrent clients through the real store and merge pipeline, with zero silent loss and zero resurrection of deleted elements across that run, and with roughly seven in ten genuinely colliding operations resolved automatically under an explicit, auditable rule rather than a guess — the remainder correctly escalated to a person, because some disagreements about a model are not the software's to settle. That reconciliation surface exists precisely because the network was removed from the editing path; a centrally served repository does not need it, because it never allows the divergence that makes reconciliation necessary in the first place. Choosing local-first is choosing to take on that engineering surface deliberately, in exchange for removing per-click latency from the working day.

There is a second honest limit worth naming plainly. A shared workspace still has to exist somewhere reachable, eventually, for any of this to function as collaboration rather than as several people quietly working alone. CelinQ does not eliminate the need for a server; it changes what depends on that server being instantaneously reachable. And "independent of WAN" describes the editing loop specifically — it does not mean every feature of the platform is equally indifferent to connectivity. Seeing a colleague's very latest change, the one they saved thirty seconds ago on the other side of an ocean, still requires a connection to arrive at some point before it can appear in front of you; presence information about who else is currently in a diagram is only as fresh as the last heartbeat that reached the server; and an administrator reviewing the Control Plane's live monitoring view is, in that moment, doing something that genuinely does depend on the network being up. What has changed is where connectivity matters: it has been pushed out of the one place — the ordinary act of opening, editing, and saving a model — where it used to matter every single time, and confined instead to the places where it always genuinely belonged: making sure everyone eventually sees the same truth, and proving, with an audit trail rather than an assurance, that nobody's work went missing while they got there.