One Authority Per Invariant
The principle that makes distributed systems consistent makes organisations accountable
Part VII — Scaling Decision-Making follows Part VI’s record discipline — principles, (A)DR, and the pathology of “we already decided.” Here the same authority question from Commitment Is Not Enough meets scale: how do organisations and systems enforce invariants without global locks, approval chains, or shared mutable state?
Every business has rules that must not be violated. A customer cannot spend more than their available balance. A seat cannot be sold twice. An order cannot be fulfilled from inventory that does not exist.
These are invariants — conditions that must hold true at all times. In distributed systems, enforcing them is hard because events arrive concurrently, from multiple sources, without coordination. The traditional answer is locking: lock the relevant state, check the condition, make the change, release. Locking works. It also scales poorly, creates contention, and couples everything that touches the same state.
There is a different approach. Not because software engineers discovered it first — the financial world has used it for half a century. The principle is this: you enforce invariants not by locking state, but by controlling who writes. It is the architectural form of the authority question from Commitment Is Not Enough: not just who is allowed to commit, but who is the single authority accountable for this truth — the single authority per invariant principle.
The single writer principle
An invariant is a property that must hold true across a set of facts. The simplest way to guarantee that property is to ensure that only one process ever writes to that set of facts. See the single writer principle pattern; invariant aggregates — single-writer streams that enforce an invariant — are developed in Why Atomicity Matters.
If only one process can write to the balance ledger, only one process can violate the balance invariant. A distributed coordination problem — how do multiple writers maintain consistency? — becomes a local correctness problem: does this single writer implement the invariant correctly?
The single writer is an architectural form of certification: a designated authority with exclusive write access to a specific domain. It connects directly to the commitment-quality mechanisms taken up later in this work. The difference between a certified single writer and an uncertified one is the difference between an architecture where accountability is traceable and one where it is diffuse.
The reservation pattern extends the principle without restoring synchrony. Rather than blocking while the invariant check runs, it separates reservation from commitment:
Phase 1: Reserve. A downstream process requests a hold on a resource. The single writer checks current state and, if available, grants the reservation — reducing available capacity without committing it.
Phase 2: Proceed in parallel. Other conditions are validated concurrently while the reservation is held.
Phase 3: Commit or release. All conditions met: commit. Any condition fails: release the reservation.
A credit card authorisation is a reservation. Settlement is the commit. Void is the release. The card network is the single writer for the credit limit invariant. The pattern is half a century old. The principle is identical. (The full mechanics — sagas, expiries, cross-cutting platform domains — are the subject of a later article in the applications part.)
The bridge: Conway’s Law
In 1967, Melvin Conway observed that organisations which design systems are constrained to produce designs which are copies of their communication structures. This is Conway’s Law.
It is usually read as a warning: if your organisation is siloed, your software will be siloed. But it works in both directions. If you want your software to have certain architectural properties — loose coupling, independent deployability, clear domain ownership — the most reliable path is to design your organisation to mirror those properties first. This is the Reverse Conway Manoeuvre.
The single writer principle in software requires: one process owns one domain, others interact through well-defined interfaces, and no direct writes cross domain boundaries. The organisational equivalent is exact: one team owns one domain, others interact through well-defined interfaces, and no direct interventions cross domain boundaries.
Conway’s Law tells us that the two are not analogies. They are the same structure at different scales. An organisation that violates the single writer principle — where multiple teams can write to the same domain without coordination — will produce software that violates it too. And an organisation that enforces it will naturally produce software architectures that reflect it.
This is not a metaphor. It is a structural identity.
The organisational single writer
What does domain ownership mean in practice?
A team is the single writer for its domain when it has:
Exclusive write authority. No other team modifies the facts, rules, or decisions within this domain without going through the owning team. Not as a bureaucratic requirement — as an architectural one. Just as a database invariant cannot be enforced when multiple processes write to the same table without coordination, an organisational invariant cannot be enforced when multiple teams write to the same domain.
A well-defined interface. Other teams interact with the domain through explicit contracts: APIs, data products, decision services, defined escalation paths. The interface is the only boundary that crosses. Everything behind it is internal. This is the organisational equivalent of a service contract.
Accountability for the invariants. The owning team is accountable for the integrity of their domain. They cannot blame another team for violating it — because no other team can write to it. Accountability and authority are coextensive. One cannot exist without the other.
Observable committed outputs. The team publishes committed atomic facts — decisions made, states changed, invariants enforced — that other teams can consume as ground truth. They do not expose mutable internal state. They expose committed events.
The locking organisation — and why it does not scale
The organisational anti-pattern is the locking organisation: one where any significant decision requires sign-off across multiple functions, where teams cannot act within their domain without coordination approval, and where the whole organisation must lock for any substantive change.
The structural form has a cultural twin: consensus culture — norms that treat full alignment as prerequisite to action, dissent as friction, and a named committed decision as premature until everyone is comfortable. Gates without consensus feel harsh; consensus without gates still stalls, because nobody will commit first.
A caveat. In genuinely stable environments — slow-moving products, regulation, and customer needs — consensus culture can work well. Such contexts do not require dynamic capabilities; operational capabilities suffice. The intelligence at the centre of dynamic capabilities is less demanded, and the judgment infrastructure this series describes is less relevant there. We still treat consensus culture as an anti-pattern in this work because we address organisations that must adapt, commit under stakes, and trace accountability — and consensus norms structurally block that. Applying them where reconfiguration is required is the error; mistaking a stable-context virtue for universal governance is how locking spreads.
The pathology is the same as a distributed system with global locks.
Coordination overhead grows as O(n²). As the number of teams that must coordinate increases, the number of coordination channels grows quadratically. At ten teams, there are 45 potential coordination pairs. At twenty, there are 190. The cost of coordination crowds out the cost of the actual work. The organisation spends more effort on alignment than on execution.
Bottlenecks emerge at coordination points. In a distributed system, a global lock means that all writers queue behind the single point that holds the lock. In a locking organisation, the equivalent is a central approval function — a strategy team, a governance committee, an architecture board — through which all significant decisions must pass. The queue grows. Decision latency grows. The people who hold the lock become a bottleneck regardless of their individual capability.
The invariant is not enforced — it is negotiated. When multiple teams can write to a domain, the invariant that should be enforced becomes a matter of negotiation. Who enforces the customer data quality standard when five teams can write to the customer record? Nobody, in practice — or everybody inconsistently. The invariant exists on paper and degrades in reality.
Accountability becomes diffuse. When the answer to “who owns this domain?” is “it’s shared,” accountability evaporates. Diffuse write authority is shared ownership in practice. Failures are attributed to coordination failures, unclear requirements, or the previous team’s decisions. The commitment boundary is absent — which is exactly the negligent half of The Decision No One Made (accountability without commitment).
Dynamic capabilities and domain authority
The strategic management literature has a name for what enables organisations to thrive through change: dynamic capabilities — the ability to sense opportunities, seize them, and reconfigure existing capabilities in response to a shifting environment (Teece, Pisano, and Shuen, 1997).
Reconfiguration requires domain authority. You cannot reconfigure what you do not own clearly. If the customer data model is owned collectively by five teams, none of them can redesign it in response to a new requirement without coordinating all five. The organisation senses the need to change. It cannot seize it. The coordination cost of reconfiguration exceeds the benefit of the change. The organisation becomes rigid not from lack of will but from lack of architectural authority.
The single writer principle enables dynamic capabilities by making reconfiguration local. When a team owns a domain completely, it can reconfigure that domain in response to market signals without negotiating across team boundaries. The decision is a committed atomic act within the team’s authority. Other teams consume the new committed facts as they would any domain event. Adaptation is a property of the architecture, not a special-case coordination effort.
This is why organisations that have invested in clear domain ownership — Amazon’s single-threaded ownership model, the team topologies of stream-aligned teams with platform support — consistently outperform organisations with shared ownership in their ability to respond to change. The advantage is not cultural. It is architectural.
Commitment boundaries in organisational decisions
The commitment boundary — the point where analysis becomes a committed decision — exists in organisations as it does in software. The same framework applies.
A cross-domain decision — one that affects multiple teams’ domains simultaneously — is the organisational equivalent of a distributed saga. It requires explicit coordination across boundaries. Each domain owner consents to the change that affects their domain. That consent is a committed act — a committed atomic fact from the organisational single writer for that domain.
The commitment boundary framework applies directly:
Named authority. Who committed to this decision? One person or one team is accountable. Not a consensus of implicitly aligned stakeholders.
Evidence snapshot. What information was available at the moment of commitment? What was not available? The commitment is accountable to the information it had, not to information that emerged later.
Policy. Under what rules was this decision made? What were the criteria? A decision made without explicit criteria is not a decision — it is a preference.
Moment. When was the commitment made? The temporal anchor matters. “We decided to enter this market” must be anchored to a specific date under which the evidence available at that date justified the decision.
The locking organisation produces many discussions and few committed decisions. The accountable organisation produces fewer discussions and more committed decisions — each traceable, each revisable by a new committed decision, each accountable to the authority that made it.
What scales
The principle is the same at both levels.
A distributed software system scales when: write authority is localised to single writers per domain, components interact through well-defined interfaces, invariants are enforced at the boundary rather than negotiated across it, and coordination is replaced by observable committed events.
An organisation scales when: decision authority is localised to single owners per domain, teams interact through well-defined interfaces, accountabilities are enforced at the boundary rather than negotiated across it, and alignment is achieved by consuming committed decisions rather than participating in every deliberation.
The cost of coordination in both cases grows with the number of coordination points. The solution in both cases is to reduce coordination points by clarifying authority. More authority, less coordination. More accountability, more speed.
Conway’s Law makes this precise: the software and the organisation are not separate problems. They are the same problem. The organisation that designs clear domain ownership will build systems with clear domain ownership. The organisation that tolerates shared write authority will build systems that tolerate it too — and pay the consistency price in both.
The next article is the mechanics: how a single writer enforces hard constraints across concurrent events without commit-time locks — Enforcing Invariants Without Locks.