The Centralized Hub Problem: What Happens When Everything Must Pass Through One Point

Opening Scene

An orb web is built around a hub, a dense point at the center where every radial strand converges. When a fly strikes the outer edge, the impact sends a vibration racing inward along that strand toward the spider waiting at the center. On a small web, the trip is instant. On a large one, strung across a wide gap with many long radials, the same vibration takes measurably longer to arrive, and if the hub itself is damaged, every strand’s signal arrives at a spider that can no longer respond to any of them.

In Plain English

A centralized data architecture works the same way. One team owns ingestion, transformation, and serving for the entire organization, and every request for a new data source, a schema change, or a fresh report routes through that same single point of coordination. It works cleanly when the organization is small enough that the central team can hold the whole business in its head. Past that point, the hub itself becomes the bottleneck standing between the organization and its own data.

The Old Way

Before the hub problem was recognized and named for what it was, most organizations simply kept centralizing further:

Every new data source, no matter how small, had to be onboarded by the same central team, regardless of how well positioned another team might have been to do it faster.
A single central team’s roadmap became the whole organization’s roadmap for data, because there was no other route to production data.
Central teams accumulated secondhand knowledge about domains they didn’t actually work in, translating requirements through documentation and meetings instead of relying on people who lived inside the business context daily.

Naming the hub as the actual bottleneck is the first step toward the domain-oriented model the rest of this series builds toward.

What’s Changing (and Why AI Is the Reason)

Growth in both data volume and the number of consumers has made the arithmetic of centralization worse every year, turning a workable model into a structural constraint.
This mirrors a shift already underway in infrastructure more broadly — this content library’s dedicated multi-cloud and hybrid strategies series covers the parallel move away from single points of control toward distributed, resilient design, and the same logic applies here.
AI-driven demand for data multiplies the number of “requests” hitting the hub by orders of magnitude, as agents and copilots generate dozens of small, ad hoc queries a human analyst never would, turning a queue that was merely annoying at human scale into something untenable at agent scale.

The Metaphor, Fully Extended

The Web	The Real Concept
Every strand converging on one central hub	Every data request routing through one central team
A vibration from the web’s edge taking longer to reach the spider the more strands lie between them	A data request queueing behind every other request already waiting on the central team
Damage to the hub threatening the whole web’s response, not just one section	An outage or bottleneck in the central team stalling delivery for every domain at once
A web that only grows larger, never adding a second hub, straining under its own size	A centralized data platform whose complexity grows faster than its central team can absorb

For Beginners: What to Actually Do

Notice, in your own organization, how many different kinds of requests currently route through one data team, and how long each typically waits.
Learn to distinguish a genuine capacity problem from a genuine architecture problem — more headcount on the central team treats the symptom, not the structure.
Get comfortable with the idea that centralization was a reasonable starting point, not a mistake, and that its limits show up only past a certain scale.

For Practitioners and Leaders: The Deeper Layer

Map current request volume against central team headcount over the last few years, and look for the point where the ratio started working against you.
Distinguish problems the central team can genuinely fix by hiring from problems only a structural change in ownership can fix.
Use this diagnosis as the business case for the domain-oriented ownership model covered next, since leadership buy-in usually requires naming the bottleneck concretely first.

Quick Recap

A single central hub coordinating all data requests works well at modest scale.
As data volume and the number of consumers grow, that hub becomes a structural bottleneck, not just a capacity shortfall.
AI-driven demand multiplies request volume in ways that make centralization strain even faster.
Naming the hub problem precisely is the first step toward the decentralized alternative this series builds toward.

Where This Fits in the Series

Article 1 untangled the vocabulary of mesh and fabric; this second article names the specific problem — the centralized hub — that both ideas exist to solve. Article 3 turns to the first half of the fix: domain-oriented ownership, where each part of the web is spun by the team closest to it.