The Best Architecture Removes Components

People associate good architecture with the image of something erected — more building blocks, more structure, more provisions. This story tells of the opposite: an architecture whose value lay in having less. It is deliberately kept general — no system, no people involved, no date.

Situation

Between a system and the services it talked to stood hundreds of intermediary API servers — a separate one for every connection, every purpose. Each one on its own did little that stood out; together they formed a sprawling, hard-to-survey landscape that had to be operated, monitored and kept alive.

Initial assumptions

This landscape had not come about through one decision, but through many small ones, each obvious in isolation: for every new need, another intermediary server, because in the moment that was the simplest way. The unspoken assumption was that every purpose deserves its own piece of infrastructure — that more connections mean more servers.

Problem

As the number of components grew, what grew was not capability but the burden of operating them. Hundreds of near-identical servers are hundreds of places where something can fail, go stale, and has to be monitored and updated. The infrastructure carried hardly more capability than a lean one would, but many times the effort and attack surface. The complexity lay not in what the system could do, but in what it was made of.

Root cause

The cause was that many near-identical intermediaries repeated themselves in a pattern that could have been captured once but never had been. What hundreds of servers did individually was, at its core, the same task — accepting requests, forwarding them, translating them. This sameness was the actual structure; it lay in plain sight, but nobody had treated it as one thing, only as hundreds.

Decision

The decision was to replace the many near-identical components with a single one that performs their common task in one place — a proxy architecture. Not adding something, but consolidating what was repeated and removing the rest. The progress consisted in there being less at the end.

Implementation

The common task of the many intermediaries was extracted and expressed in one place — a proxy that does what had previously been scattered across hundreds of servers. One by one, the individual servers were replaced and removed, each only once the proxy had demonstrably taken over its task. The end result was a markedly simpler infrastructure: fewer components, fewer points of failure, less to keep in your head.

Trade-offs

Consolidation has a price: the one proxy becomes important — it now carries what was previously distributed and must be correspondingly robust and observable. You trade many small points of failure for one significant one. That is a good trade as long as that one point is carefully built; it would be a bad one if it were not. We would decide differently if the intermediaries were genuinely different — then you would be consolidating unlike things and forcing a unity that does not exist.

What we learned

The best architecture often removes components instead of adding new ones. Capability and count are not the same thing: a system made of many near-identical parts is not more powerful than one that solves the same task in one place — just more expensive to operate. Wherever something repeats many times over, there is almost always a structure that can be captured once. The tempting question is which component to add; the more valuable one is which repetition to dissolve.

How it changed Batunet

Since then, we see a growing number of near-identical components as a signal, not as the normal state — as a hint of a structure not yet captured. With infrastructure, we first ask what can be consolidated and removed before we add anything. For us, the goal is the simplest architecture that carries the task, not the richest.

Further reading

• Story: Removing complexity instead of adding it — the same lesson, applied to an application's architecture instead of infrastructure.
• Guide: Modular monolith vs. microservices — why more components do not mean more capability.
• Guide: API design for long-lived systems — expressing a common task cleanly in one place.
• Guide: Software that still runs in ten years — why fewer parts make a system longer-lived.

It is grounded in the Batunet Engineering Method: recognize repetition as structure, consolidate instead of multiplying, choose the simplest viable architecture.

More components are not more architecture. Often the best design is the one after which less is left standing — and that little carries the whole.