CelinQ Insights · No. 33

Enterprise Architect Over VPN: How Network Latency Affects Modelling Performance

A VPN tunnel does more than encrypt a connection — it adds its own processing to every one of the thousands of small requests EA sends.

The complaint arrives in almost the same words from almost every organisation that runs Enterprise Architect over a corporate VPN: it worked fine in the office, and now that half the team works from home, or from a branch office, or from a client site, the model has become sluggish enough that people have started avoiding it. The instinct is to blame the VPN itself, as though the encryption were somehow slowing the data down, and that instinct is not entirely wrong, but it is incomplete. A VPN adds real overhead, and it adds that overhead to precisely the kind of workload — many small, sequential, latency-sensitive requests — that suffers the most from it. Understanding exactly what a VPN adds, and where, is the difference between a vague sense that "the network is slow" and a concrete plan for what to do about it.

Why a VPN adds latency beyond the raw distance

Every network path has a baseline round-trip time set by physical distance and the number of hops between two points, and that baseline exists whether or not a VPN is involved. A VPN adds to that baseline in several distinct ways. First, there is the tunnel itself: your traffic is encapsulated inside another protocol, encrypted, and sent to a VPN gateway or concentrator, which then has to decrypt it, de-encapsulate it, and forward it on to its real destination — and the response has to make the same trip in reverse. That encapsulation and encryption work is not instantaneous; it is real processing time added to every packet, on top of whatever distance the packet has to travel. Second, the VPN gateway itself is very often not on the direct path between you and the database server. Traffic frequently gets routed through a central concentrator in a specific data centre or region regardless of where you and the database server actually are, which means a VPN can add distance to a path that, without it, might have been considerably shorter. An architect working from a home office twenty kilometres from a data centre can find their traffic routed through a VPN concentrator hundreds of kilometres in the opposite direction before it doubles back, adding a genuinely large detour to a trip that geography alone would have made short.

Third, VPN gateways are shared infrastructure, and shared infrastructure has capacity limits. During peak hours, when an entire organisation's remote workforce is connecting through the same concentrator, queuing delays at the gateway itself can add further latency on top of the tunnel overhead and the routing detour, and this component is the hardest for any individual user to diagnose, because it varies by time of day and has nothing to do with their own connection quality. Put these three effects together — encryption and encapsulation processing, routing detours through a concentrator, and queuing under shared load — and it becomes clear why a VPN connection so often measures noticeably worse in round-trip time than a direct connection over the same physical distance would.

Why many small interactions matter more than a few large ones

As covered elsewhere in this series, Enterprise Architect's interaction with a repository is not one large transfer followed by local processing; it is a continuous stream of small, granular reads and writes — properties, tagged values, diagram objects, connectors — issued more or less every time you click or type. This is precisely the workload pattern that suffers most from added latency and least from added bandwidth. A large file transfer, the kind a VPN handles comfortably, pays the round-trip cost once and then streams data at whatever throughput the link supports. A chatty protocol like EA's repository access pays the round-trip cost again and again, once per small request, so a VPN's overhead — even a seemingly modest twenty or thirty extra milliseconds of round-trip time — gets multiplied by however many hundreds of small requests a working session generates. This is why users often describe the VPN as making EA "feel heavy" rather than pointing to any one operation that is obviously broken: no single request fails or times out, but the cumulative weight of small delays changes the entire texture of the working session.

Latency versus throughput, one more time

It bears repeating in the specific context of VPNs because the confusion here is especially common and especially costly to fix wrongly: a VPN that offers generous throughput can still feel unusably slow for interactive modelling if its round-trip time is high, because throughput determines how fast a large payload moves once transfer begins, while round-trip time determines how long you wait before each small request even starts returning an answer. Organisations sometimes respond to VPN complaints by upgrading the VPN gateway's bandwidth capacity, assuming a bigger pipe fixes a slow connection, and are then surprised when EA feels exactly as sluggish as before. The gateway was never short of bandwidth for EA's tiny queries; it was adding round-trip time through encryption overhead and routing detours, and no amount of additional bandwidth touches that specific cost.

Branch offices and home offices are not the same problem

It is worth separating these two common scenarios, because they fail differently. A branch office typically has a fixed, site-to-site VPN connection with known, relatively stable characteristics — a consistent round-trip time that an IT team can measure once and expect to hold, aside from the shared-load queuing effect during business hours. The problem there tends to be a stable but elevated latency floor: modelling is uniformly a bit heavier every day, all day, and the fix, if there is one within the existing architecture, is usually about reducing the number of round trips a given operation requires rather than about chasing an intermittent fault. A home office connecting over a client VPN application is a different and often worse case, because the connection quality is far less controlled: a residential internet connection with its own contention, a VPN client competing with video calls and other traffic for the same uplink, and often a less direct route to the concentrator than a purpose-built site-to-site link would offer. The result is not just higher latency but more variable latency — the same operation that took two seconds a moment ago might take five seconds now, for reasons the user has no visibility into and no way to control, which is its own particular kind of frustrating because the unpredictability makes the tool feel unreliable rather than merely slow.

Remote database access patterns and where the pain concentrates

Not every EA operation costs the same number of round trips, and understanding which ones are expensive helps explain why some tasks feel disproportionately painful over a VPN. Opening a diagram with many objects is expensive because it resolves each object, its underlying element, and its connectors as separate reads. Running a traceability or dependency query across a broad section of the model is expensive because it walks relationships outward, often issuing a new query for each hop. Generating documentation or a report is expensive for the same reason multiplied by however many elements the report covers. By contrast, editing a single element's name or a single tagged value is comparatively cheap, because it is close to one read and one write. Teams often describe their VPN experience inconsistently — "it's mostly fine, except when I try to generate a report" or "diagrams are the worst part" — and that inconsistency is not a mystery once you notice that these are precisely the operations with the highest round-trip count, and therefore the operations where a VPN's added latency compounds the hardest.

Simulating VPN conditions in a controlled way

Before concluding that a specific architecture is the fix, it is worth measuring the actual cost of your specific VPN rather than assuming it from general principles, because the honest answer really does vary by organisation. A controlled test introduces network emulation — the same kind of round-trip-time shaping described in the performance article in this series, set to values that match your VPN's measured characteristics at different times of day — between an EA client and the repository, and times a representative set of operations at each latency level, reporting median and P95 rather than a single best case. Running the same test with the VPN in place versus a direct connection at the same physical location isolates specifically how much of your team's pain is the VPN's own overhead as opposed to raw geographic distance, and that distinction matters because the two have different fixes: geographic distance is not something a VPN configuration change will solve, but concentrator routing and gateway capacity often are.

Split tunnelling and other VPN-side mitigations worth trying first

Before reaching for a different modelling architecture, it is worth exhausting the VPN-side options, because some organisations genuinely do have room to improve without changing anything about how EA itself works. Split tunnelling — routing only traffic destined for genuinely internal resources through the VPN, while letting other traffic take its normal direct path — can sometimes shorten the route to a repository server if the concentrator was previously adding an unnecessary detour, though it does nothing for the encryption and encapsulation overhead itself, and it introduces its own security review burden that many organisations are, reasonably, cautious about taking on. Placing a second VPN concentrator closer to a concentration of remote users, rather than routing everyone through one central location, can reduce the geographic detour for the affected group, at the cost of additional infrastructure to secure and maintain. Upgrading a saturated gateway's capacity genuinely helps the queuing-under-load component, though as covered above it does nothing for the two other components — encryption processing and routing detours — so it is worth diagnosing which component actually dominates your organisation's specific pain before spending on a fix aimed at the wrong one. None of these are wrong moves, and a well-tuned VPN with a well-placed concentrator can measurably narrow the gap. What none of them can do is eliminate the round trip itself, because the fundamental design still requires one for every interactive repository operation; they can only make that round trip somewhat cheaper.

A worked example: reconnecting after a dropped tunnel

It helps to walk through what reconnection actually looks like end to end, because "it handles it gracefully" is not a satisfying claim on its own. Picture an architect on a home VPN that drops for roughly ninety seconds partway through a morning, a common enough event on a residential connection under load. In the traditional shared-repository model, that ninety-second gap is not a background inconvenience; it is a foreground failure. Whatever operation was in flight when the tunnel dropped — a save, a query, a diagram load — fails outright, EA may show a connection error, and the architect has to wait out the gap doing nothing useful before resuming exactly where the interruption occurred, hoping nothing was left in an inconsistent state by the failed operation.

Under CelinQ, the same ninety-second gap is close to a non-event from the architect's chair. They were editing a local repository the entire time; the VPN drop affects only the background agent's ability to reach the CelinQ Server, and the agent's response to that is simply to keep the affected changes in its durable local queue and retry on its normal cycle. The architect keeps typing, keeps saving, keeps opening diagrams, all against local storage that never noticed anything happened. When the tunnel comes back, the agent resumes its queue, pushes what accumulated during the gap — journaled locally the whole time, so nothing from those ninety seconds is at risk — and pulls down anything colleagues published in the meantime, reconciling it through the same Fusion merge used for any other reconnection. The architect experiences the drop, if they experience it at all, as nothing more than a slightly longer delay before their morning's work shows up for everyone else, rather than as ninety seconds of lost productivity and a save they have to remember to retry.

A VPN was built to make a connection safe, not to make it fast. Judging it as though speed were ever its job is how organisations end up chasing a bandwidth upgrade that was never going to touch the actual complaint.

The local-first alternative

CelinQ's response to the VPN problem is the same structural response described for WAN latency generally: remove the round trip from the interactive path rather than trying to make the round trip itself cheaper. Each architect's EA session reads and writes a genuinely local repository, so whatever the VPN is doing — adding encryption overhead, routing through a distant concentrator, queuing under load — is simply irrelevant to the experience of clicking an element or opening a diagram, because that click never asks the VPN for anything. The VPN, or any other network path, only carries the background synchronisation traffic between the local agent and the CelinQ Server, and that traffic is tolerant of latency and jitter in a way interactive modelling never can be, because nobody is sitting and watching a progress bar waiting for it to finish before they can continue working.

Smart Sync behaviour over unstable VPNs

An unstable VPN — one that drops and reconnects, or that varies wildly in latency depending on load — is a genuinely hard environment for any synchronising system, and it is worth being specific about how CelinQ behaves in it rather than asserting it handles everything gracefully. The background agent's synchronisation cadence is not a fixed metronome; an event-driven fast path debounces bursts of local edits into a coherent change roughly a few seconds after you stop typing, a safety synchronisation runs on the order of once a minute to catch anything the fast path missed, and a deeper reconciliation runs every five minutes to compare the full local state against its last known snapshot. None of these layers assume the network is reliably present. If a push fails because the VPN has dropped, the change stays safely queued locally and the agent simply tries again on its next cycle; there is no failure mode where an interrupted synchronisation corrupts the local repository or loses the change, because the change was durably recorded locally before the network was ever involved.

The offline queue and replay, specifically for flaky connections

A VPN that drops for ninety seconds every few minutes is, from the local repository's point of view, functionally indistinguishable from full offline operation repeated many times over, and this is precisely the scenario CelinQ's durable offline queue is built for. Local changes are journaled before any network attempt is made, so a dropped VPN mid-synchronisation never risks the local work; the queue simply holds what has not yet been confirmed and resumes exactly where it left off once connectivity returns, tolerant of duplicate delivery in case a confirmation was lost in the drop rather than the underlying push itself. The same mechanism that makes a multi-hour flight safe to work through is what makes a VPN that drops every few minutes a non-event rather than a recurring small crisis.

Reconnection behaviour

When a flaky VPN finally stabilises, or a dropped connection comes back, the agent does not simply resume blasting queued changes as fast as the link allows, which would be a poor way to treat a connection that has just proven itself unreliable. It re-establishes its session, resumes the queue in order, and lets the Smart Sync cadence — tightened automatically if the server's presence registry detects active concurrent collaboration on the same diagram — govern the pace from there. Any changes that arrived on the server from other clients while you were disconnected are pulled down and reconciled against your local work through the same deterministic Fusion merge used everywhere else in the system, so reconnecting after a VPN outage looks exactly like reconnecting after any other offline period: a brief catch-up, handled automatically, with genuine conflicts surfaced rather than guessed at.

The honest limits

None of this makes the VPN's underlying problems disappear, and it would be misleading to suggest otherwise. If your organisation's VPN concentrator is badly routed or badly undersized, those are real infrastructure issues worth fixing on their own merits regardless of which modelling architecture sits on top of them, because plenty of other traffic besides Enterprise Architect rides the same tunnel and suffers the same overhead. CelinQ's local-first design removes the VPN from the interactive modelling loop specifically; it does not make the VPN faster for anything else your team does over it, and the background synchronisation, while tolerant of a poor connection, still ultimately needs a connection often enough to keep the shared workspace from drifting too far out of date, particularly for teams that rely on near-real-time visibility into each other's changes. A VPN that is offline for days at a stretch, rather than minutes, will eventually mean a meaningfully stale local view of what colleagues have done, even though nothing is lost and everything reconciles correctly once connectivity resumes.

It is also worth being honest about the limits of the worked reconnection example above. Ninety seconds is a manageable gap by any architecture's standards; the same reasoning holds for VPN interruptions measured in minutes, but an organisation whose VPN is genuinely unusable for hours at a stretch has a problem that goes beyond what any client-side architecture can fully absorb, because the local repository will keep working but the team's shared view of each other's progress will lag correspondingly further behind. Local-first design widens the window of acceptable network unreliability considerably; it does not make network reliability irrelevant.

There is also a genuine question of scope worth naming honestly: some organisations' VPN pain is not really about Enterprise Architect at all, but about a wider set of applications that legitimately do need a live connection to central infrastructure, and for those applications, no amount of local-first modelling architecture helps, because the problem lives elsewhere in the stack. What CelinQ can honestly claim is narrower and more defensible: for the specific, measurable pain of Enterprise Architect feeling heavy over a VPN, removing the round trip from the interactive path removes the actual cause, and that claim is one worth testing with a controlled benchmark against your own VPN's measured characteristics rather than taking on trust.