Architecture Must Earn Its Complexity
Every service boundary, deployment unit, database and network hop must solve a problem worth its ongoing cost. This nine-part series gives founders, product teams, architects and engineers a practical way to choose between a monolith, a modular monolith and distributed services without treating microservices as a maturity badge. It covers boundaries and module contracts, what changes when local calls become network calls, schema ownership in a shared database, microservices as an organisational architecture, the operational tax nobody budgets for, extracting a module together with its data, automated fitness functions that stop boundaries eroding, and how AI coding agents can accelerate either discipline or sprawl. It follows Magaliesberg Provincial Supplier Desk, a fictional provincial supplier-support platform; its systems and figures are illustrative. Research claims were checked on 5 November 2026.
9 articles
- Part 1Your new system probably does not need microservices. It does need boundaries.Part 1 of Architecture Must Earn Its Complexity. Most new systems gain more from clear module boundaries, owned data and explicit contracts than from independent services on day one. A decision model, a fictional provincial platform and the evidence a team must show before any module leaves home.8 min read
- Part 2A modular monolith is not a folder structurePart 2 of Architecture Must Earn Its Complexity. Six tidy folders do not make six modules. A module needs a published contract, hidden internals, owned data and a dependency direction that the build enforces, or it will quietly decay back into one tangled application.8 min read
- Part 3Local calls became network calls. Now what?Part 3 of Architecture Must Earn Its Complexity. When a module becomes a service, every call to it can now be slow, fail, arrive twice or succeed without the caller knowing. A call conversion register that turns each former function call into an explicit network design decision.9 min read
- Part 4One database does not mean shared ownershipPart 4 of Architecture Must Earn Its Complexity. A modular monolith can run on one database server without letting every module touch every table. Schemas, roles, migration ownership, transaction rules and a controlled reporting path keep data ownership real until, and unless, a module leaves.8 min read
- Part 5Microservices are an organisational architecturePart 5 of Architecture Must Earn Its Complexity. A service boundary is also a promise about who builds, runs, pays for and answers for a piece of software. Count the owners before you count the services, and align boundaries with teams that will exist for years.8 min read
- Part 6The distributed-systems tax nobody put in the business casePart 6 of Architecture Must Earn Its Complexity. Business cases for microservices usually price the compute they might save and leave out the recurring cost of running more moving parts. A ledger of the distributed-systems tax, in four groups, and how to weigh it against the benefit.8 min read
- Part 7Extract the module with its dataPart 7 of Architecture Must Earn Its Complexity. Moving a module's code into a service while leaving its tables behind produces a distributed monolith. A staged, strangler-style extraction with exit evidence and a rollback point at every stage, worked through for a verification module that needed its own security boundary.8 min read
- Part 8Architecture fitness functions for the modular monolithPart 8 of Architecture Must Earn Its Complexity. Module boundaries decay one reasonable shortcut at a time. Automated architecture fitness functions in five families, run at three points in the delivery path, with an exemption register that expires, keep the boundaries you designed from quietly disappearing.8 min read
- Part 9How AI coding agents change the architecture choicePart 9 of Architecture Must Earn Its Complexity. Coding agents make code cheaper to write, not systems cheaper to run. They amplify whatever structure they are given: clear modules become easier to change, and loose boundaries erode or sprawl faster. Five rules for using agents inside an architecture that must earn its complexity.8 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala