Subsidiarity as a Distributed Systems Principle

Distributed systems are usually introduced as an engineering response to scale, latency, and failure. Put computation near the people who need it; replicate what cannot be lost; coordinate independent machines; and continue serving some operations under specified failures. These are technical decisions. They are also decisions about where authority lives, whose knowledge counts, and who must wait for permission.

Catholic social thought offers a principle for asking those questions: subsidiarity. It is often summarized as “keep decisions local,” but that summary is incomplete. Subsidiarity protects the initiative and proper competence of persons and smaller communities while requiring higher communities to help them accomplish what they cannot accomplish alone. The higher level must not absorb the lower one merely because it can. Nor may it abandon a local community when a wider authority is needed to secure justice, coordinate a shared good, or protect the vulnerable.

This is not a theological proof that every application should be peer-to-peer, federated, or local-first. It is a way to examine architecture. A system designed according to subsidiarity asks which decisions belong to a person, a household, a team, a congregation, a municipality, a nation, or a global service; what assistance each level owes the others; and what should happen when authority, knowledge, or responsibility is in the wrong place.

Subsidiarity Is More Than Decentralization

The principle received its classic modern formulation in Pius XI's Quadragesimo Anno. The encyclical argues that it is a grave wrong for a larger and higher association to take over what smaller communities can do, because the proper activity of social life should be preserved and supported. It also describes higher bodies as having a duty to coordinate, assist, and direct toward the common good when a lower body is unable to act effectively. Subsidiarity therefore has both a limit and a summons: do not usurp; do help.

The Compendium of the Social Doctrine of the Church makes the same structure explicit. It presents subsidiarity as protection against the concentration of power and as recognition of the initiative of intermediate communities. But it does not turn every local decision into an untouchable right. A higher authority can intervene when necessary, and its intervention should be inspired by solidarity and directed toward the development of the lower community rather than its permanent replacement. The principle is relational: levels of social life are distinct, mutually responsible, and ordered toward a common good.

That account differs from a slogan such as “smaller is always better.” A local group can be coercive, captured, technically incapable, or unable to address harm that crosses its boundary. A central institution can sometimes be the only actor able to protect equal rights, pool resources, provide expertise, or prevent a race to the bottom. The question is not whether authority is geographically near. It is whether authority is exercised at the level competent to address the matter, with the least unnecessary displacement of the agency below it.

The Distributed-Systems Analogy

In a distributed system, no single machine necessarily has a complete view of the state. Nodes have local observations, local resources, and local failure modes. They must decide what can be handled without a round trip and what requires coordination. A design that sends every action to one remote coordinator may simplify global ordering, but it adds latency, creates a bottleneck, and makes the coordinator a high-value point of failure. A design that lets every node act without any shared rule may remain available while producing conflicts no one can resolve.

Subsidiarity illuminates this tradeoff without collapsing into it. A local decision is not morally superior simply because it avoids a network call. The point is that the actor closest to a decision may possess relevant knowledge and bear direct responsibility for its consequences. Higher coordination is warranted when the effects cross boundaries, when local resources are inadequate, or when a common rule is needed to protect the standing of persons who would otherwise be powerless.

The analogy also has limits. A process, replica, or service is not a human community. It has no dignity, conscience, or claim to participation. Technical locality cannot establish moral legitimacy, and a protocol cannot fulfill the duties of solidarity by itself. Distributed-systems concepts can make authority visible and constrain it; they cannot decide what human beings owe one another.

Locality, Competence, and the Right to Act

The first architectural question is not “How do we decentralize this?” It is “Who is situated and competent to decide it?” A person should ordinarily control ordinary preferences, private records, and the ways a tool assists their work. A team may be best placed to interpret its operating context. A local institution may know which language, custom, accessibility need, or emergency condition a global platform cannot see.

Local-first software offers one technical expression of this insight. Data and core operations can remain available on a person's device or within a community even when the network is absent. Synchronization then becomes a means of cooperation rather than a prerequisite for every act. Replicated state, conflict resolution, and user-controlled storage can preserve initiative at the edge. The result is not automatically humane: a lost device, a bad merge, or a weak recovery path can harm a person. Local control must be paired with understandable backup, portability, accessibility, and a way to repair conflict.

The same reasoning applies to policy. A global service might provide common primitives—identity protection, encryption, abuse reporting, data export, and interoperability—while permitting communities to shape ordinary practice within defined limits. A municipal network might operate its own services while relying on shared standards for routing and emergency communication. The point is not to multiply isolated islands. It is to preserve meaningful jurisdiction where local knowledge and responsibility are real.

Assistance Is Part of the Principle

Subsidiarity is distorted when its prohibition on absorption is remembered but its duty of assistance is forgotten. A small community cannot be told to “own its data” if it lacks the money, expertise, or bargaining power to secure it. A local school cannot be praised for autonomy while being denied the infrastructure required for accessibility. A person cannot be handed an encryption key and called free if recovery, support, and recourse are available only to experts.

In technical terms, higher layers should provide enabling infrastructure rather than unnecessary command. They can offer documented interfaces, reliable defaults, shared security updates, capacity during emergencies, translation, training, and mechanisms for resolving disputes between jurisdictions. Assistance should enlarge the lower unit's ability to act. It should not quietly turn a grant, API, or safety service into permanent dependency on an authority that can change the rules without notice.

This is where subsidiarity meets solidarity. Solidarity asks whether people recognize obligations to one another, especially across unequal power. Subsidiarity asks where those obligations should be organized and how higher authority can serve without taking over. A platform that leaves every moderation decision to isolated communities may preserve local discretion while permitting predictable abuse. A platform that imposes one global rule for every context may prevent some abuse by erasing legitimate difference. Justice requires a layered answer: local judgment where local judgment is competent, shared safeguards where harms travel, and assistance where capacity is unequal.

Boundaries, Failure, and the Need for Coordination

Every distributed system has boundaries. Data may be partitioned across nodes; services may be administered by different organizations; a federation may allow independent servers to exchange messages. These boundaries can protect privacy and limit blast radius. They can also make global facts difficult to establish. A system must decide which state is authoritative, how conflicts are detected, and who can act when a local participant violates a shared obligation.

Distributed computing teaches that communication is not free and that failures are not always obvious. Networks can be delayed or partitioned; clocks can disagree; nodes can crash or send contradictory messages. Consensus protocols, leases, quorum rules, and conflict-free data structures address particular coordination problems under stated assumptions. None of them creates a universal answer to the question of who should have authority. A quorum can establish what a protocol accepts while leaving open whether the rule was just, whether a person was heard, or whether the result can be appealed.

Subsidiarity therefore requires explicit boundary design. Which decisions remain local during a network partition? Which events must be synchronized before another action is safe? Who can declare an emergency, for how long, and subject to what review? If two communities have incompatible rules, is there a neutral process for negotiation, exit, or adjudication? A system that cannot answer these questions has not eliminated central power; it has left it implicit in defaults, operators, or whoever controls the recovery path.

Federation Is Not Automatically Subsidiarity

Federation is attractive because independent servers can implement a common protocol while retaining separate administrators and communities. It can reduce dependence on a single provider, support migration, and allow local norms within interoperable boundaries. But a federation can still reproduce concentrated power. One server may become too large to leave; a handful of infrastructure providers may host most instances; protocol maintainers may control changes; and users may have no practical voice in any of these institutions.

Nor is peer-to-peer architecture a synonym for participation. A network may distribute packets while concentrating software updates, identity, wealth, or the ability to exclude. It may make abuse harder to investigate or shift the burden of safety onto people least able to bear it. “No central server” describes a topology, not a social order. The relevant audit asks who can set defaults, alter the protocol, revoke access, recover an account, inspect data, and obtain a remedy.

Conversely, a central service is not automatically contrary to subsidiarity. A small community may rationally delegate payment settlement, certificate validation, or emergency coordination to an institution with specialized competence. The delegation becomes problematic when it is broader than the task, impossible to review, difficult to leave, or used to displace decisions the local unit could responsibly make. Good architecture makes the delegation narrow, legible, reversible where possible, and answerable to those affected.

The Case for a Central Coordinator

An objection deserves a direct answer. Global coordination can be faster and safer. A single identity provider may stop account takeover more effectively than thousands of small providers. A central incident response team may contain a worm before local administrators understand it. A national or international rule may be necessary when pollution, fraud, harassment, or data extraction crosses every local boundary. Why romanticize fragmentation?

Subsidiarity does not require fragmentation. It recognizes that some goods are genuinely common and some failures cannot be contained locally. A higher authority may coordinate them, set a floor of protection, or act directly when lower units cannot. But necessity should be demonstrated rather than assumed. The coordinator should state the problem it is solving, the authority it needs, the evidence for its intervention, and the conditions for returning discretion below. Emergency powers should expire or face review; shared services should publish interfaces and obligations; and those affected should have appeal, oversight, and a practical route to change providers when the context permits.

Centralization can also be a form of assistance when it gives weaker communities capabilities they could not obtain alone. A shared security team, public-interest cloud, or common accessibility layer may protect local institutions better than a market in which each must negotiate alone. What matters is whether the higher layer strengthens the lower layer's agency or makes it a client with no meaningful power to refuse.

A Design Review for Subsidiarity

A practical review can translate the principle into engineering questions without pretending that a checklist settles prudence. First, name the decision, not merely the feature. Is the system deciding what a person may see, whether a payment clears, how a community resolves a dispute, or whether a public emergency has ended? Different decisions have different proper authorities and different stakes.

Next, map knowledge and responsibility. Who has the context needed for a sound judgment? Who bears the consequences? Who can correct an error? Does the actor making the decision have an accountable relationship to the people affected, or is the decision produced by a distant service optimized for a metric? If local authority is being displaced, what concrete incapacity justifies the displacement?

“Competent” should be tested rather than used as a flattering label. Reviewers can record the local unit's knowledge of the affected people, the scale and cross-boundary effects of the decision, security and continuity requirements, accessibility, accountability, and the availability of remedy. Evidence might include recovery time after a device loss, successful migration, error and appeal rates, participation by people with disabilities or limited connectivity, and the burden of operating the system. These are decision aids, not a mechanical moral score: a local unit can know a context well and still violate rights, while a higher service can be more secure and accessible.

Then inspect the interfaces between levels. Can a community configure legitimate local practice without forking itself out of existence? Can it export data and migrate? Are security updates, documentation, and support actually available? Are common rules understandable and contestable? Does a central layer expose enough evidence for lower actors to verify its claims, or does it demand obedience to an opaque result?

Finally, model failure and power. What happens during a partition, a compromise, a leadership change, or a dispute between communities? Which actions remain possible locally? Which safeguards must be shared? Who can invoke an override, and who can revoke it? Is the exception narrow and temporary, or has an emergency become the permanent architecture? A design that performs well in the normal case but concentrates irreversible power in recovery is not subsidiarity-respecting merely because its everyday requests are distributed.

Consider two counterexamples together. A local-first health or benefits record may preserve service during a network partition, yet a lost device or conflicting merge can strand the person unless recovery and synchronization work. A centralized identity or emergency service may provide stronger continuity and equal access, yet its operator can become a single point of surveillance or exclusion. The subsidiarity question is which failure is more serious for this population, what measurable safeguard reduces it, and who decides when the lower level is no longer capable. That inquiry keeps the analogy from turning topology into legitimacy.

From Topology to a Way of Belonging

The deepest value of subsidiarity is not that it produces a fashionable network diagram. It is that it refuses two false pictures of social life. In one, every person is an isolated consumer who must solve every problem alone. In the other, every meaningful decision is absorbed into a total system that calls dependence efficiency. Subsidiarity describes a layered common life in which persons and communities have real initiative, receive real help, and remain responsible for how they use it.

That picture is compatible with sophisticated infrastructure. We can build replicated services without pretending that replicas are communities. We can use cryptographic proofs without treating proof as wisdom. We can coordinate across borders without making every local difference a defect. We can centralize a narrowly defined function while keeping governance, data, and remedy closer to the people whose lives are at stake.

The test is therefore not “Is this system decentralized?” It is: What must be shared, what may remain local, who is competent to decide, and what assistance is owed when competence is unequal?Those questions turn subsidiarity from a decorative appeal to decentralization into a discipline of power. They ask engineers to design not only for uptime and throughput, but for agency, responsibility, solidarity, and repair.

A distributed system worthy of the human person will not seek to make every node sovereign or every decision global. It will place authority where knowledge and responsibility can meet, coordinate what truly exceeds local reach, and make higher power serve rather than swallow the life below it. That is subsidiarity as a distributed-systems principle: not the abolition of coordination, but the ordering of coordination toward a common good in which persons and communities can act, belong, and become more capable of helping one another.

Sources and Qualifications

The Catholic account here draws especially on Pius XI's Quadragesimo Anno, §§79–80, for the protection and assistance owed to smaller communities; the Compendium of the Social Doctrine of the Church, §§185–188, for subsidiarity's positive and negative dimensions and its relationship to solidarity; and the Catechism of the Catholic Church, §§1883–1885, for the ordering of social authority toward the common good. These sources are paraphrased, not quoted, and they do not prescribe a particular software topology. The essay treats subsidiarity as a principle for prudential judgment, not as a rule that locality, federation, or decentralization is always preferable.

The technical discussion is informed by Saltzer, Reed, and Clark's “End-to-End Arguments in System Design” for placing functions at the layer with the knowledge required to perform them; Lamport's work on distributed systems and Byzantine agreement for the limits and costs of coordination under failure; and Kleppmann's account of replication, consistency, partitioning, and conflict resolution in Designing Data-Intensive Applications. These works describe engineering properties, not moral conclusions. A local-first or federated design can still be unjust, and a central service can sometimes provide necessary assistance. The argument depends on examining competence, accountability, cross-boundary effects, and practical agency in each system.