The first architecture slide for the fictional Magaliesberg Provincial Supplier Desk showed eleven services, a container cluster, a service mesh, a message broker and a separate database for each service. It looked modern and it looked serious. Thabo Molefe, the tech lead, counted the people who would build and run it: seven, including himself and a product owner. "Who carries the pager for eleven things?" he asked. Nobody on the steering committee had an answer, because nobody had asked the question before the slide was drawn.
The Magaliesberg Provincial Supplier Desk is a fictional provincial supplier-support platform. Suppliers register, submit compliance documents, have those documents verified, receive notifications, raise and track cases, and the department reports on all of it. One delivery team builds it. Every person, figure and system in this series is illustrative, and all data is synthetic.
This series argues that architecture is an economic and organisational choice. Every boundary, deployment unit, database and network hop must solve a problem worth its ongoing cost. Part 1 sets out the decision model and the path the Supplier Desk took instead of the eleven-service slide.
Microservices are not a maturity level
Teams often talk about architecture as a ladder: monolith at the bottom, microservices at the top, and a modern organisation climbs. That framing is wrong, and it is expensive. A monolith, a modular monolith and a set of microservices are three different trade-offs. Each fits some systems and harms others.
The comparison above is CloudNala's working model. It is a default hypothesis, not a rule, and the third column is the one business cases tend to leave blank.
Martin Fowler made the practical version of this argument in 2015. In MonolithFirst he argued, while noting that the evidence was still sparse, that "you shouldn't start a new project with microservices". He also noted that the view "is by no means unanimous", and not every practitioner agrees. In MicroservicePremium Fowler described the extra cost and risk of a distributed design as a premium that "often gets projects into serious trouble". Microsoft's own microservices architecture style guide (checked on 5 November 2026) lists the trade-offs plainly: more moving parts, harder testing across services, network latency, data consistency without a single transaction, versioning, and a team that must have the skills to run a distributed system. None of those sources says microservices are wrong. They say the benefits have a price, and the price is paid from the first day.
Shopify's engineering team described a different route in 2019. In Deconstructing the Monolith they explained that they "wanted a solution that increased modularity without increasing the number of deployment units". That sentence is close to the whole argument of this series. Modularity and distribution are separate decisions. You can have the first without paying for the second.
Start from capabilities, change and ownership
The eleven-service slide began from a service count. The Supplier Desk team started again from three questions.
- What are the business capabilities? Registration, document submission, verification, notifications, case management and reporting. Each has its own vocabulary and its own rules. A "supplier" in registration is a legal entity with directors; in case management it is a party to a query.
- What changes together, and what changes alone? Verification rules change when the department's compliance policy changes, perhaps twice a year. Notification templates change weekly. Case workflows change when the support desk learns something.
- Who owns each capability? One team of seven owns everything today. That fact alone answers most of the distribution question.
From those answers the team drew six modules, not six services. Each module owns its logic, its data and a published contract. Calls between modules stay in the same process, so a call from cases to registration cannot time out, does not need a retry and can run inside one database transaction when it genuinely must.
The Supplier Desk design
The design is one deployable application with six modules and one database server holding six owned schemas. Three rules make it a modular monolith rather than a monolith with tidy folders.
- Contracts, not reach-ins. A module may call another module only through that module's published interface. The internal classes of verification are invisible to cases.
- Owned data. Each module has its own schema. No module reads or writes another module's tables. Reporting gets data through a controlled read path, which Part 4 covers.
- Visible dependencies. Allowed dependencies are declared, and cycles are forbidden. The build fails if a forbidden dependency appears. Part 8 shows how that is enforced.
The team also wrote down, on the first day, which modules were likely candidates for extraction later and why.
Notifications might one day need to scale and fail independently, because suppliers receive bursts of SMS and email messages before tender closing dates and an outage at a messaging provider should not slow down document upload. Verification might one day need its own security boundary, because it will call an external verification source with credentials the rest of the application should never hold. Both are hypotheses. Neither is a reason to build a service now.
Name the extraction triggers before you need them
Our earlier article on when a module should become a microservice sets out five tests to apply before any extraction. This series adds a step in front of those tests: write the triggers down while the system is still a modular monolith, and record the baseline that will tell you when a trigger has fired.
The Supplier Desk recorded six possible triggers:
| Trigger | What would count as evidence | Baseline recorded now |
|---|---|---|
| Independent scaling | One module's load pattern forces the whole application to scale | CPU and request rate per module, peak and normal weeks |
| Independent release cadence | One module's changes wait on others' testing, measured in days | Lead time per module, release blockers by cause |
| Fault isolation | Failures in one module degrade unrelated user journeys | Incidents by module and by affected journey |
| Security boundary | A module needs credentials, network paths or audit controls others must not share | Data and credential inventory per module |
| Technology constraint | A module needs a runtime or store the rest cannot use | Known constraints, with dates |
| Durable team ownership | A separate team will own the module for the long term | Team structure and funding line |
Each row is measurable. None of them says "best practice", "future scale" or "everyone is doing it". Those phrases are not evidence. They are reasons to ask for evidence.
The extraction evidence gate
When a trigger appears to fire, the Supplier Desk's rule is that any proposal for a new service must pass an evidence gate before design work starts. The proposal must:
- Name the specific problem. Not "scalability", but "notification bursts before closing dates delay document upload".
- Show current evidence. Measurements from the baseline, not projections.
- State the expected improvement. In the same unit as the evidence, so the result can be checked.
- Name the service owner and the data owner. People, not a team label.
- Budget the operating controls. Timeouts, retries, idempotency, tracing, alerting, on-call, pipelines and environments. Part 6 turns this into a ledger.
- Set a review date. A date on which the team checks whether the extraction delivered the improvement, and is allowed to say it did not.
The gate is deliberately small. It takes an afternoon for a real problem and is very hard to complete for an imagined one. That is the point. As our Agents on the Night Shift episode showed, a clean diff that splits a system into services can hide an operating bill that nobody priced.
When distribution is right from the start
A modular monolith is the Supplier Desk's default hypothesis, not a universal answer. Some systems should be distributed from the first release:
- Regulated or contractual separation. Where a regulator, a contract or a security classification requires a component to run in a separate environment with separate administrators, the boundary is a requirement, not a choice.
- Geographic or edge placement. A component that must run close to devices or in a particular location cannot share a process with the rest.
- Genuinely separate products. Two products with different customers, teams and release cycles that happen to share a login are two systems.
- Already-autonomous teams. An organisation with several funded, long-lived teams may be better served by aligning services to them from the start. Part 5 returns to this.
Even then, the discipline is the same: name the reason, show the evidence and price the operating cost. A distributed design that cannot explain its boundaries is not more mature. It is harder to change.
A short checklist for a new system
Before you draw a deployment diagram, answer these in writing:
- Which business capabilities exist, and what vocabulary does each use?
- Which capabilities change together, and which change alone?
- Who owns each capability, and for how long?
- What is each module's contract, and which dependencies are allowed?
- Which schema does each module own, and how will others read its data?
- Which modules are extraction candidates, and which trigger would justify each?
- What baseline are you recording now, so that the trigger can be tested later?
- Is there any regulatory, contractual or physical reason to separate a component from day one?
If you cannot answer the first five, more services will not help. They will make the missing answers more expensive to find. Our article on the architecture decisions startups regret shows how early structural choices compound, and Architecture decides the bill covers the cost side.
Key points
- Monolith, modular monolith and microservices are trade-offs, not maturity levels. Each has a cost the business case should name.
- Modularity and distribution are separate decisions. Most new systems need the first long before they need the second.
- Design modules around business capabilities, change patterns and ownership, with contracts, owned data and visible dependencies.
- Write extraction triggers and baselines down while the system is still a modular monolith.
- Any new service must pass an evidence gate: problem, evidence, expected improvement, owners, operating budget and review date.
Next: Part 2, A modular monolith is not a folder structure. All parts are on the series page.
How CloudNala can help
CloudNala runs architecture complexity reviews for new and growing systems. We work with your team to map capabilities, change patterns and ownership, design module boundaries and data ownership, set the extraction triggers and baselines, and write the evidence gate your organisation will use before approving any new service, so that every boundary you build has a reason you can defend.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Complexity Review or write to us at consult@cloudnala.co.za