Every architecture decision sits on a dial. Some dials are subtle. AT5 — Centralisation vs Distribution — is not one of them. You are choosing whether a single authority owns a piece of state, or whether many nodes share ownership of it. There is no middle option that gets you both consistency and availability.
The decision shows up everywhere. A single database server (centralised) vs a distributed database cluster (distributed). A central API gateway (centralised) vs a service mesh with sidecars (distributed). A single team owning a platform component (centralised ownership) vs each team owning its slice (distributed ownership). Same tradeoff. Different layer.
The Dial
A central authority is easy to reason about and easy to make consistent. One source of truth is consistent by definition. There is only one place to write. There is only one place to read. There is no possibility of disagreement because there is no second copy.
A distributed system has no single point of failure but requires coordination protocols. Multiple copies of state must be kept aligned. Writes must propagate. Reads from different replicas can return different values during the propagation window. Achieving consistency requires consensus, which costs latency and complexity. Achieving availability under partition requires accepting that copies may temporarily disagree.
That is the whole tradeoff. Both are valid. Neither is universally correct.
Setting the Dial
Two heuristics:
Strong consistency requirements → centralisation is easier. If your domain cannot tolerate disagreement — financial ledgers, inventory counts that drive purchase decisions, distributed locks — start centralised. One source of truth that everyone reads from is the simplest mental model and the easiest to make correct. The cost is that the central component becomes a SPOF (FM1) and a bottleneck under load.
High availability requirements → distribution is safer. If your domain cannot tolerate the central component being down — global services, multi-region deployments where one region failing must not take down the others — start distributed. The cost is the coordination overhead and the consensus protocols required to keep distributed state aligned.
The two requirements are in tension. CAP theorem formalises why: in the presence of a network partition, a system must choose between consistency (refuse writes that cannot be acknowledged by all replicas) and availability (accept writes and reconcile later). A system cannot have both. AT5 is the design-time choice that determines which side of CAP the system will fall on when the partition arrives.
The Paradox: Centralised Coordinators for Distributed Systems
A distributed system with a centralised coordinator is still a SPOF at the coordinator. ZooKeeper, etcd, and similar systems are widely used as centralised coordinators for distributed systems — they solve the distributed coordination problem with careful SPOF management.
The trick is recursive: the coordinator itself runs as a small distributed system (a Raft quorum of 3 or 5 nodes). From outside, it presents as a single authoritative source. Inside, it is replicated and survives the failure of a minority of nodes.
This is the canonical pattern when you need centralised semantics without single-machine availability. The cost is two-fold: the coordinator quorum itself can lose quorum (3-node clusters survive 1 failure, 5-node clusters survive 2), and every coordinator operation now requires consensus, which is slower than a single write. The benefit is correctness — the coordinator is the only place where decisions are made, eliminating the failure modes of distributed agreement (FM12 split-brain, FM4 data consistency failure).
Where the Tradeoff Bites in Real Systems
A single database vs sharded. A single database server is the centralised end of AT5. All reads and writes hit one node. Consistency is trivial. The cost is that the database is a SPOF and limited by single-machine performance. Sharding moves to the distributed end: data partitioned across nodes, each node handling its slice. Consistency now requires cross-shard transactions or careful partition design that keeps related data on one shard. Most teams attempt sharding too early, before the operational cost is justified by scale.
A single API gateway vs service mesh. A central gateway absorbs auth, rate limiting, routing, observability — all the cross-cutting concerns — in one place. Easy to deploy policy. Easy to monitor. Becomes a SPOF and a bottleneck without horizontal scaling. A service mesh distributes the same concerns to a sidecar proxy attached to every service. No central bottleneck, but configuration must be propagated to every sidecar, which is its own coordination problem.
Central platform team vs distributed ownership. A single platform team owning all infrastructure components is the centralised model. Consistent decisions, single point of accountability, but a bottleneck for every team needing platform changes. Distributed ownership (each product team owns its slice of infrastructure) eliminates the bottleneck but produces drift: different teams make different choices, the platform fragments, the operational cost compounds.
What Centralisation Costs You
You give up availability under partition. The central component, by definition, is the failure surface for everything that depends on it. The hardest version of this is when the centralised component is "obviously fine" most of the time. Teams under-invest in its redundancy because it has not failed yet. When it does fail, the blast radius is the entire system.
You give up horizontal scalability. A single component can only handle so much load. Scaling it requires either more powerful hardware (which has limits) or sharding (which makes it distributed). The transition from centralised to sharded is often the hardest migration in a system's history.
What Distribution Costs You
You give up the simple mental model. Distributed systems require thinking about partial failures, message ordering, eventual consistency, and the possibility that two nodes hold conflicting beliefs about state. Most production bugs in distributed systems come from engineers reasoning about them as if they were centralised — assuming reads return the latest write, assuming all nodes see the same state at the same time.
You give up exact correctness for many operations. Most distributed systems accept eventual consistency for most operations and reserve strong consistency for the small set that absolutely require it. The mental cost of knowing which operations have which guarantee — and surfacing that to users — is the long tail of distributed-system complexity.
The Decision Question
When you face a new design and AT5 is in play, the question is not "should this be centralised or distributed?" — that frames the choice as ideological. The better questions:
- What is the consistency requirement of this state? (If "exact at all times," start centralised.)
- What is the availability requirement? (If "must survive a region outage," start distributed.)
- What happens during a network partition? (Whatever your answer is, that is the side of CAP you have already chosen.)
Most systems get AT5 wrong by starting distributed because distribution sounds more "scalable" or "modern." Distribution is a tax. Pay it when the availability requirement forces you to. Otherwise, centralise and survive longer.
AT5 is defined in The Engineer's Map — Framework 4 (Book 0, Chapter 8). This article extracts it in the context where the choice has the steepest cost: Book 3, Chapter 4 — Sharding and Partitioning. The book3 chapter covers range, hash, and consistent-hash partitioning strategies, the hot-key failure mode, the resharding operation, and the hardest migration in any system's history — going from centralised to sharded.