Removing Complexity Instead of Adding It

Progress is usually equated with adding: more functionality, more components, more capability. This story is about progress that consisted of taking things away. It is deliberately kept general — no system, no people involved, no date.

Situation

A monolith had external API components tightly embedded in it — parts that talked to third-party services, woven into the rest of the system's code. They did their job, but they were part of one big whole that could only be moved as a whole. Everything depended on everything.

Initial assumptions

The embedded approach had once been the obvious one: you write the call to an external service where you need it, right in the middle of the system's flow. For the first requirement, that is fast and correct. The unspoken assumption was that what was written together belongs together — that proximity in the code also means proximity in substance.

Problem

Over time, that proximity became a burden. Because the API components lived inside the monolith, they shared its fate: they could not be operated separately, scaled separately, or changed without touching the whole. A component that would have needed more resources under load could only get them by scaling up the entire system. The entanglement cost something in a place nobody had suspected when writing the code: agility.

Root cause

The cause was that proximity in the code had been mistaken for belonging together. The API components looked like part of the system because they were written inside it — but by nature they were independent: clearly delimited tasks with a clear boundary to the outside. They did not belong in the monolith; they had merely been written there.

Decision

The decision was to take away instead of adding — to extract the embedded components from the monolith and turn them into standalone APIs. No new feature, no additional capability; just a boundary drawn where one already existed but had never been made visible.

Implementation

The components were cut out along their natural boundary and re-established as standalone services behind a clear interface. The rest of the system now addressed them across that boundary instead of carrying them inside itself. The restructuring added nothing the system could not do before — it merely arranged what was already there along the lines where it truly belonged apart.

Trade-offs

Extraction is not free: a standalone API brings its own boundary that has to be operated, monitored and versioned — more moving parts, not fewer. The gain lies elsewhere: a clearer architecture and the ability to operate and scale each component independently. We would decide differently if the components truly were inseparable from the core — then extraction would be an artificial boundary separating what belongs together.

What we learned

Removing complexity is often more valuable than adding functionality. The visible progress lies in adding; the real progress often lies in taking away — in untangling an entanglement nobody noticed anymore because it had always been there. A system does not get better by being able to do more, but by it becoming clearer what belongs where. The question “what can we add?” is the tempting one; the question “what actually doesn't belong here?” is the more valuable one.

How this changed Batunet

Since then, when facing a tangled system, we first check what can be removed or extracted before considering what could be added. We treat a clear boundary as a gain, even if it brings no new capability. The most elegant restructuring is often the one after which the system contains less — but what it contains is better ordered.

Further reading

• Guide: Modular Monolith vs. Microservices — when a boundary between parts makes sense and when it doesn't.
• Decision: The Modular Monolith as a Starting Point — structure along real boundaries, not out of habit.
• Guide: API Design for Long-Lived Systems — designing an extracted capability cleanly as an interface.
• Opinion: Why Premature Abstraction Creates Complexity — why not every boundary is good, only the ones along real dividing lines.

The foundation is the Batunet Engineering Method: draw structure along real boundaries, untangle entanglement, take removing as seriously as adding.

Not all growth is progress. Sometimes the best step is to detach something from the whole so it becomes clearer what belongs where.