CelinQ Insights · No. 60

Centralized consistency vs local-first availability for Enterprise Architect

Every collaboration architecture is a bet about which failure you would rather have — this lays out both sides plainly, so you can place yours deliberately, not by default.

There is a distributed-systems idea, decades old and thoroughly proven, that sits quietly underneath every one of the twenty-nine articles that came before this one, and it deserves to be named directly rather than left implicit: you cannot have a system that is simultaneously always available for local reads and writes, always perfectly consistent with everyone else's view, and tolerant of the network occasionally failing. Something has to give, and which thing you choose to give up is not a matter of one option being more advanced than the other. It is a matter of which failure mode your team can actually live with. Enterprise Architect's shared-repository model, whether that is a raw shared database or Pro Cloud Server's more sophisticated mediation of it, chooses consistency and, in exchange, accepts that availability depends on the network. CelinQ chooses availability — every architect can always read and write, offline or not — and, in exchange, accepts that consistency arrives slightly after the fact, through synchronisation and merge rather than being guaranteed at the instant of every keystroke. Neither choice is a mistake. They are answers to different questions, and this article's job is to lay both answers out honestly enough that you can tell which question your organisation is actually asking.

What centralized consistency actually buys you

It is worth stating the case for the centralized model with the same seriousness this series has applied to CelinQ throughout, because dismissing it would be both dishonest and bad strategy — plenty of teams are well served by it, and understanding exactly why is what lets you recognise whether yours is one of them. A single, authoritative repository — whether a shared database file, a server-mediated Pro Cloud Server deployment, or any equivalent architecture — gives you a genuinely simple mental model: at any given moment, there is exactly one truth, and everyone who can currently reach the server is looking at it. There is no reconciliation step to trust, no merge engine whose correctness you have to take on faith, no possibility that two people's edits diverged for an afternoon before anyone noticed. If your team works from a single office, on a fast and reliable local network, with modelling sessions that rarely overlap in the same package at the same moment, this simplicity is not a compromise. It is close to strictly better than the alternative, because you are paying none of local-first's reconciliation complexity and receiving the full benefit of its consistency guarantee.

Centralized architecture also has a genuinely simpler operational story in specific, important ways. There is one place backups are taken from and one timeline to restore, without the discontinuity problem this series covered in the piece on restoring a server while newer client state still exists — a problem that, as that article explained plainly, simply does not arise when nobody has anywhere else to keep working during an outage. There is one access-control surface to audit rather than a fleet of laptops each holding a full local copy of potentially sensitive architectural data, which matters to some security postures more than others. And there is a long institutional track record: Pro Cloud Server in particular has been refined over many years specifically for the problem of serving Enterprise Architect repositories to distributed teams, with genuine engineering invested in reducing the WAN latency its architecture inherently exposes, a point examined directly in the piece comparing Pro Cloud Server against local-first architecture. Dismissing that engineering effort would be exactly the kind of unearned claim this series has committed not to make.

What local-first availability actually buys you

The case for local-first starts from a different set of priorities, and it is worth being equally precise about what it actually delivers rather than asserting it in the abstract. Every read and every write happens against a genuinely local repository, at the full, uncompromised speed of the machine in front of the architect, regardless of network conditions — not a cached, degraded fallback mode, but the primary and only way modelling happens in this architecture at all. This eliminates, structurally rather than through optimisation, the entire category of problem covered in the pieces on Sparx performance over a network and Enterprise Architect over VPN: there is no round trip on the interactive path to speed up, because there was never a round trip there to begin with. And it eliminates the sharper, more disruptive failure mode covered in offline collaboration — a server outage, a VPN drop, a flight, a client site with a hostile guest network — because none of those events touch an architect's ability to keep working. The work simply continues, queued locally, waiting for a connection that may return in five minutes or five hours, and either way nothing about the modelling experience itself was ever degraded while it waited.

The other half of local-first's case is less obvious and, in a sense, more interesting: it replaces pessimistic locking with optimistic collaboration, backed by a merge engine specifically built to make that trade defensible rather than reckless. The piece on locks or convergence covers this trade-off in full, but the short version bears repeating here because it is the crux of the whole comparison. A locking model prevents conflicts by forbidding concurrency — you cannot create a genuine conflict if only one person is ever allowed to touch a given piece of the model at a time, and the price is the queue, the waiting, and the coordination overhead this series opened with in its very first article. An optimistic, local-first model allows the concurrency and reconciles afterwards, and the entire question of whether that trade is worth making rests on whether the reconciliation can be trusted. CelinQ's answer is Fusion: a deterministic, proof-carrying three-way merge engine, covered across the pieces on conflict resolution and proof-carrying merges, that resolves the large majority of genuine collisions automatically, with a stated rule code rather than a black-box guess, and escalates the remainder to a human decision rather than picking a winner by timestamp. In the seeded, reproducible 100,000-operation benchmark documented for this engine, roughly seven in ten colliding operations resolved automatically through that deterministic path, with zero silent loss and zero resurrection of deleted material across five concurrent clients — the kind of specific, checkable number this series insists on rather than a vague claim of "handles conflicts well."

Centralized architecture prevents conflicts by forbidding concurrency. Local-first architecture allows concurrency and reconciles it afterwards. The entire question of which one is right for your team reduces to whether you trust the reconciliation more than you value never having to wait for a lock.

Conflict prevention versus conflict reconciliation, examined honestly

This distinction deserves more than a single paragraph, because it is genuinely the philosophical centre of the whole comparison, and most discussions of it collapse into a false dichotomy — "locking is safe, merging is risky" — that does not survive contact with how either system actually behaves under real use. Locking is safe against one specific failure mode: two people overwriting the same fact without either knowing about the other. It achieves that safety at a real and continuous cost, paid every single day in coordination overhead, and it achieves nothing at all against a different failure mode that matters just as much: an architect who has no connection to the shared repository simply cannot work, full stop, and the safety the lock provides is irrelevant to someone who was never able to reach it in the first place.

Reconciliation-based merging is safe against that second failure mode by construction — nobody is ever blocked from working — and its safety against the first failure mode, the genuine concurrent-edit collision, depends entirely on the quality of the merge engine behind it. This is not a minor caveat; it is the whole ballgame, and it is exactly why this series has spent so much of its length on Fusion's internals rather than treating "we merge changes" as a throwaway feature bullet. A naive merge system that resolved every conflict by picking whichever change arrived last would be genuinely more dangerous than a lock, because a lock fails loudly and in advance — you know immediately that you cannot proceed — while a bad automatic merge fails silently and after the fact, and you might not discover the lost work for weeks. The honest comparison, then, is not "locking versus merging" as an abstract philosophical choice. It is "the coordination cost of locking versus the engineering quality of a specific merge engine," and any organisation evaluating local-first architecture, from CelinQ or any competitor, should interrogate the merge engine specifically rather than accepting "we handle conflicts" as a sufficient answer.

Operational complexity: where it actually sits, not where it appears to

A common intuition holds that centralized architecture is operationally simpler and local-first is operationally more complex, and that intuition is only half right, because it measures complexity from the wrong vantage point. From the server administrator's chair, centralized architecture genuinely is simpler in the specific sense described earlier: one database, one backup target, one place to look when something goes wrong. But operational complexity does not vanish when you centralize it; it moves to a different desk. In a centralized architecture, the complexity lands on the network and on IT support: diagnosing why a specific branch office's connection to the shared database is slow, negotiating firewall exceptions for database ports across VPN tunnels, fielding the recurring support tickets from architects locked out of a package by a colleague who forgot to release it. In a local-first architecture, that specific complexity disappears, but a different complexity appears in its place, concentrated in the reconciliation layer: running and monitoring a synchronisation server, understanding Fusion's rule codes well enough to trust them, occasionally resolving the human-decision capsules Fusion escalates, and — as the piece on deployment patterns covers in detail — choosing and operating wherever that server actually lives.

Neither total is obviously smaller than the other; they are complexities of a genuinely different character, and which one an organisation finds easier to staff for is a real, legitimate factor in the decision. A team with strong network engineering and IT support, comfortable managing VPN infrastructure and database access grants, may find the centralized model's operational burden entirely familiar and manageable. A team without that capacity, or one whose architects are scattered enough that network administration would be a constant, recurring cost, may find local-first's concentrated-but-occasional reconciliation work considerably lighter in practice, especially once Smart Sync and Fusion are doing most of that work automatically and only the genuine edge cases ever reach a human.

How Smart Sync and Fusion change the calculation, specifically

It is worth being concrete about the two mechanisms that make local-first a genuinely defensible choice today rather than a theoretically appealing but practically risky one, because both directly address the objections a sceptical evaluator would reasonably raise. The first objection is usually about staleness: if everyone is working against their own local copy, how out of date does that copy get before it becomes a practical problem? Smart Sync's answer, covered fully in its own piece on Smart Sync, is a layered cadence rather than a single fixed interval — a fast, debounced path that pushes changes within seconds of an edit under normal conditions, a safety synchronisation roughly every minute to catch anything the fast path missed, and a deeper reconciliation roughly every five minutes to recover from drift the other two layers could not see. In practice, for a connected architect, "local-first" does not mean "working from data that might be hours stale." It means working from data that is, under ordinary conditions, seconds to a couple of minutes behind the absolute latest state, which is a categorically different proposition than the manual, hours-or-days-stale reconciliation this series has repeatedly contrasted it with.

The second objection is about trust: even if reconciliation happens quickly, can it be trusted not to make a bad decision silently? Fusion's answer is to make every automatic decision explicit and checkable rather than opaque — every proven auto-merge carries a specific rule code, such as DISJOINT_PROPERTY_WRITES for two people editing different properties of the same element or MAP_DISTINCT_KEYS for two people adding different tagged values, so an administrator reviewing the Fusion log is never asked to simply trust that a merge was correct; they can see exactly why it was judged safe. And every collision Fusion cannot prove safe is not guessed at — it becomes an explicit capsule, presented with the base, local, and remote versions side by side, for a human with actual context to resolve. Together, these two mechanisms are what allow the availability half of the trade-off to be taken without accepting the reckless version of it that gives optimistic collaboration a bad reputation in less careful implementations.

Who should choose centralized

Drawing this out plainly rather than leaving it as an exercise for the reader: a team is well served by a centralized, locking-based architecture when its architects work predominantly from one location on infrastructure they trust to be fast and reliable, when offline work is a rare exception rather than a routine part of how the team operates, when the organisation already has strong network and database administration capacity and would rather spend that capacity than build a new operational competency, and when the simplicity of "there is exactly one place the truth lives, always" is worth more to the team's culture and risk tolerance than the throughput gained by removing the queue. Regulated environments that specifically require every read to pass through a single, continuously monitored access point — rather than accepting that a full local copy of the model exists on every laptop, however securely — may also find that a centralized model satisfies a specific compliance requirement more directly than a local-first one, even though local-first's own access-control and audit story, covered in the piece on access control, is a real and serious answer to the same underlying concern.

Who should choose local-first

A team is well served by local-first architecture when its architects are genuinely distributed — across offices, across client sites, across time zones — such that a single fast network path to one database is not a realistic assumption to build a working day around. It is the right choice when offline work is not an edge case but a routine part of the job: consultants working from client premises with restrictive guest networks, architects who travel for workshops and want to keep modelling on the journey home, teams spanning regions where a single low-latency link to one server is simply not achievable regardless of budget. It is the right choice when the coordination overhead of locking has become a measurable drag on a growing team — the scaling problem examined in the piece on scaling architecture practice, where the cost of contention rises faster than the size of the team causing it. And it is the right choice for organisations that specifically want data sovereignty over infrastructure they run themselves, since CelinQ's server, in any of the deployment patterns covered separately, still runs entirely within the organisation's own boundary; local-first and self-hosted are complementary properties here, not a trade-off against each other.

An objective way to decide, rather than a preference

Reduced to its essentials, the decision comes down to answering a small number of concrete questions honestly about your own team, rather than about the technology in the abstract. How often, in a typical week, does an architect need to work without a reliable connection to wherever the shared repository lives — never, occasionally, or routinely? How large and how geographically distributed is the team, and is that distribution likely to grow? How much of the current workflow's friction is actually attributable to locking and coordination, as opposed to genuine, unavoidable disagreement about the model's content? What operational capacity does the organisation already have, and does it lean toward network and database administration or toward monitoring a synchronisation and merge layer? And, honestly, what does the organisation's risk tolerance say about trusting a deterministic, auditable merge engine over the categorical guarantee of "only one person can touch this at a time" — recognising that the merge engine's specific track record, not the general idea of merging, is what should inform that answer?

None of these questions has a universally correct answer, and any vendor who tells you otherwise, including one selling a local-first product, is not being straightforward with you. What they have is a specific, checkable answer for your specific team, and reaching it honestly is worth more than adopting whichever architecture happens to be more fashionable to discuss this year.

The comparison laid out dimension by dimension

It helps to walk through the same handful of dimensions side by side, in the same order, for both architectures, so the comparison reads as one coherent picture rather than as scattered arguments across several sections. On raw interactive performance, centralized architecture is only ever as fast as the network path to the server allows, while local-first is fast unconditionally, because the interactive path never touches that network at all — this is the one dimension where the difference is closest to absolute rather than a matter of trade-offs. On consistency, centralized architecture offers an unconditional guarantee at every instant, while local-first offers eventual consistency measured in the seconds-to-minutes Smart Sync typically achieves, which is a real difference but a narrower one in practice than it sounds in the abstract. On availability during a network or server outage, centralized architecture stops working entirely for everyone, while local-first continues without interruption for every architect, queuing the eventual synchronisation. On conflict handling, centralized architecture prevents conflicts before they occur by forbidding concurrent access, while local-first allows concurrency and resolves the resulting collisions through Fusion, automatically for the documented majority and through an explicit human decision for the rest.

On operational burden, centralized architecture concentrates complexity in network administration and access-control support, while local-first concentrates it in operating a synchronisation and merge layer — a different total, not a smaller one, and the right answer depends on which kind of capacity an organisation already has. On data residency, centralized architecture keeps exactly one copy of the model in one place by design, while local-first keeps a full copy on every architect's laptop in addition to the canonical copy on the server, which some security postures will weigh as a cost and others, given local-first's own token authentication, TLS, and audit trail, will judge as an acceptable one. On growth, centralized architecture's coordination cost tends to rise faster than team size because every additional person is another potential source of lock contention, while local-first's reconciliation cost rises more gently, bounded largely by how often people genuinely edit the same specific facts rather than by team size on its own. None of these seven comparisons declares an overall winner, and that is the point: an organisation weighing them honestly against its own specific circumstances will usually find that most of the dimensions point the same direction for its situation, and that direction is the actual answer, not whichever architecture arrived first in the conversation.

Honest limits, on both sides

It would be a poor way to close a flagship comparison to pretend the local-first side of this trade-off is free, and it is worth restating the honest costs named throughout this series rather than letting the argument end on a triumphant note it has not earned. Local-first architecture's safety rests entirely on the merge engine being trustworthy, and trust in a merge engine has to be earned through transparency — proof-carrying rule codes, an inspectable revision history, an honest published benchmark — not asserted by marketing copy. It introduces a genuine cultural adjustment for teams used to the certainty of a lock, replacing "nobody else can touch this while I hold it" with "the system will tell me honestly if someone else did." It concentrates a form of operational responsibility — running the synchronisation server, understanding Fusion, occasionally resolving capsules — that a purely centralized team never has to build at all. And, as the piece on backup and restore covered in detail, it introduces failure modes of its own, like a server restored from an older backup meeting laptops that never lost anything, that a purely centralized architecture never has to reason about because it never allowed the divergence to occur in the first place.

Centralized architecture's costs are equally real and have been the honest subject of the first twenty-five articles in this series: the queue, the coordination tax that grows faster than the team, the offline architect who simply cannot work, the WAN latency that turns every interactive click into a small wait. Both architectures are legitimate, mature answers to the same underlying problem, built by people who took the trade-offs seriously rather than pretending they did not exist. The job of this article was never to declare a winner. It was to give you the actual terms of the trade, stated plainly enough, so that whichever one you choose, you chose it for your team's real working pattern rather than for a slogan.