Centralised versus Distributed

Definition

The question appears at every level: one database or many, one platform team or embedded engineers, one deployment pipeline or per-team pipelines, one shared library or duplication.

What centralisation buys and costs

Buys: consistency, economies of scale, a single place to fix things, easier compliance, and less duplicated effort.

Costs: it becomes a bottleneck; it must serve every case, so it serves none perfectly; and it creates a coupling point where a change requires coordination.

The decisive question is whether the centralised thing is on the critical path of other teams' delivery. A shared component that everyone must change to ship anything is a delivery constraint for the whole organisation, however elegant it is.

The pattern that resolves most instances

Centralise the mechanism, distribute the decision. A platform team provides a paved road — templates, pipelines, defaults — that is the easiest path, and teams choose to use it. They can deviate, at their own cost. This gets the economies of scale without the bottleneck, and it forces the platform to be genuinely good rather than merely mandatory.

The failure mode at both extremes is well documented: full centralisation produces a queue at the platform team's door and shadow infrastructure built to avoid it; full distribution produces twelve incompatible ways to deploy a service and no ability to make an estate-wide change.

How the answer changes with scale

At twenty engineers, centralisation is free — everyone is in one conversation. At two thousand, the same centralisation is a bottleneck, and the coordination cost that distribution was meant to remove reappears at a different layer.

The reverse also holds: distribution at twenty engineers means twenty different solutions to the same problem and nobody available to maintain any of them.

This is why the same decision is right and then wrong, and why the revisit conditions should be written down at the time — the decision is rarely wrong when made and frequently wrong later.

Failure scenarios

• A shared component every team must change, becoming the organisation's release constraint.
• A platform team as a ticket queue, routed around by shadow infrastructure.
• Distribution without standards, so nothing can be changed across the estate.
• Centralisation of the wrong thing — the mechanism should be shared; the domain decision should not.

Interview question

"When does a shared platform stop helping and start constraining, and what signal tells you?"