Centralised vs. Decentralised Control

The thing that strikes me about this particular topic is how often people hear 'decentralised' and assume it means better. As though the mere absence of a hierarchy is itself an achievement.

To be fair, that instinct isn't entirely irrational. A single point of failure is a genuine liability. If your control centre goes down, your entire system goes down with it. That's not a trivial concern.

No one is disputing that. The point is that 'it could break' is not, on its own, a design philosophy. Centralised control exists because coordinating agents toward a globally optimal solution is actually quite hard when everyone is doing their own thing.

Which is precisely why the lesson doesn't declare a winner. The whole argument is that the environment determines the architecture. Predictable, stable setting — centralised probably makes sense. Dynamic, unpredictable — decentralised handles that better because it doesn't have a coordinator that can become a bottleneck.

And yet if you gave most people a system to design, they would pick one they liked the sound of and then construct reasons afterward. 'We went decentralised because resilience.' Resilience to what, exactly? They haven't the faintest idea.

That's a criticism of bad engineers, not of decentralised systems.

It is. I don't retract it.

What I find genuinely interesting here is the bottleneck problem with centralised control. It's not just about failure — it's about scale. The coordinator becomes a cognitive ceiling for the entire system. At some point, routing everything through one decision-maker is itself the inefficiency.

That is a reasonable observation. Although I'd note that decentralised systems introduce their own ceiling, which is coordination overhead. When agents are negotiating peer-to-peer, you're spending resources on the negotiation itself. It doesn't vanish — it just gets distributed, which people seem to find aesthetically pleasing for reasons I've never fully understood.

Because distributed failure is less catastrophic than total failure. You lose one agent in a decentralised system, the others adapt. You lose the control centre in a centralised system, you've lost everything. That asymmetry matters in high-stakes environments.

In high-stakes environments, yes. In a warehouse logistics system running on a Tuesday, probably not the decisive factor. Context, as the lesson does at least attempt to make clear, is the entire point.

You're being unusually reasonable about the lesson.

The lesson is structured adequately. My reservations are about the people who will read it, nod along, and then three weeks later describe their preference for one architecture as though it were a principled stance rather than a vibe.

And the way to not be that person is to actually work through the trade-offs for the specific problem in front of you. Which is, rather conveniently, exactly what the lesson asks you to do.

Yes. It's almost as though the learning objective was designed with a purpose. One can only hope the gesture is returned in kind.