Lesson 2 of 2
A Decision Method: Monolith, Modular Monolith, or Microservices
A repeatable, weighted method that turns the most-argued question in the industry into a defensible recommendation with traceable evidence.
This is the decision that consumes more meeting hours than any other in software architecture, and it is usually settled by whoever argues most confidently. It does not have to be. The method below produces a recommendation you can defend, shows the evidence behind each input, and — most usefully — makes it obvious when the honest answer is "we do not know yet, and here is what would tell us".
The three options on the same criteria
Traditional monolith
One deployable, no enforced internal boundaries. Fastest to start, and the structure degrades unless something holds it.
- Lowest possible ceremony for a small team
- Atomic transactions and one-commit refactoring anywhere
- One thing to deploy, secure, monitor and run locally
- Coupling grows silently and is expensive to reverse later
- No ownership boundaries, so teams collide as headcount grows
- Extraction later starts with an archaeology project
Choose when: A team of up to about five people, an unproven product where the domain is still changing weekly, and a genuine intention to add boundaries once the shape settles.
Modular monolith
One deployable with enforced module boundaries and per-module data ownership. The default recommendation.
- Keeps atomic transactions and a single operational surface
- Gives ownership boundaries without operational cost
- Keeps extraction cheap, so the decision stays reversible
- Requires discipline and a build-time check to enforce
- No independent scaling or independent deployment
- One bad release can still affect everything
Choose when: Almost always: any team from roughly five to fifty people without a measured need for independent scaling, deployment or availability.
Microservices
Several independently deployable services, each owning its data, communicating over a network.
- Independent deployment, scaling and failure domains
- Teams can choose technology and release cadence per service
- A component with extreme requirements can be treated differently
- Eventual consistency in any operation spanning services
- Permanent platform, tracing, contract-testing and on-call overhead
- Every call site needs timeouts, retries, idempotency and fallbacks
Choose when: A measured need for one of the four strong signals, plus the organisational capacity to operate services — typically 30 or more engineers with a platform capability.
The method
Six steps from question to defensible recommendation
- 1
1. Write the quality attributes down with numbers
Availability per critical path, latency at a percentile, expected load growth over 24 months, tolerable staleness per screen, deployment frequency needed per team. Chapter 1 established that an attribute without a number cannot be designed for or traded — this is where that bites hardest.
- 2
2. Score the four strong signals against evidence
Differential scaling: does any component's resource profile differ by 10x or more? Release blocking: how many incidents last quarter, counted? Differential availability: does a component have a distinct availability commitment? Runtime need: does a workload require a runtime the monolith cannot host? Each is yes, no, or unknown — and "unknown" is a legitimate and important answer.
- 3
3. Assess organisational readiness honestly
Engineer count, number of teams, existence of a platform capability, current deployment frequency, on-call maturity, and whether the product organisation will accept eventual consistency in named flows. A no on the last item is disqualifying for any operation that would span services.
- 4
4. Apply the weights and compute
Weight the strong signals heavily and readiness as a gate rather than a score: strong signals decide whether services would help, readiness decides whether you could survive them. A high signal score with low readiness means "not yet, and here is what to build first" — not "go".
- 5
5. Choose the smallest step that tests the conclusion
If the answer is services, extract exactly one — the component the evidence points at — and run it for a quarter before committing to more. One extraction reveals more about your organisation than any amount of planning.
- 6
6. Record the decision, the evidence and the revisit trigger
An architecture decision record naming the numbers used, the alternatives rejected and the specific measurement that would change the answer. Without a trigger, a deferred decision quietly becomes a permanent one.
| Criterion | Weight | Scores 1 (monolith) to 5 (services) |
|---|---|---|
| Differential scaling need | 3 | 1 = uniform profile; 3 = one component 3-5x; 5 = one component 10x or more, measured |
| Release blocking between teams | 3 | 1 = under 5 incidents/quarter; 3 = 10-20; 5 = over 30 after cheaper fixes tried |
| Differential availability requirement | 3 | 1 = one target for everything; 5 = a component with a distinct contractual commitment |
| Runtime or technology need | 2 | 1 = one stack suits all; 5 = a workload the monolith genuinely cannot host |
| Domain boundary clarity | 2 | 1 = boundaries still moving monthly; 5 = stable bounded contexts, owned and enforced for a year |
| Tolerance for eventual consistency | 2 | 1 = product requires immediate consistency everywhere; 5 = named flows may be eventually consistent |
| Operational readiness (gate) | Gate | Under 30 engineers, no platform capability, or no on-call maturity caps the outcome at modular monolith |
In practice
Working the method on a real decision
A 34-engineer scale-up in logistics, five teams, one modular monolith with enforced boundaries for two years. Leadership wants a decision on microservices before the next funding round. Route optimisation bursts to 25 times baseline CPU for minutes at a time; everything else is steady.
Constraints
- Route optimisation: 25x CPU bursts, measured over six months
- Release blocking: 7 incidents last quarter, after pipeline work
- One availability target of 99.9% across the product
- Product accepts eventual consistency for route results, not for bookings
- A two-person platform capability exists; on-call is per team and functioning
Decision
Extract route optimisation only, keeping everything else in the modular monolith. Re-measure release blocking in two quarters and revisit if it exceeds 20 incidents.
Why
Scoring the sheet: differential scaling 5 (weight 3 = 15), release blocking 2 (weight 3 = 6), differential availability 1 (weight 3 = 3), runtime need 2 (weight 2 = 4), boundary clarity 5 (weight 2 = 10), consistency tolerance 3 (weight 2 = 6). Total 44 out of 75, with the readiness gate marginally passed. That lands squarely in the "extract the one component with the strongest signal" band, and the strongest signal is unambiguous — route optimisation, at 25x, with results the product agrees may be eventually consistent.
What it cost
The extraction cost eight weeks and added a queue, a service and a fourth on-call rotation, and route results are now up to 30 seconds behind a booking change — acceptable because the product explicitly agreed it, and unacceptable for bookings, which is why bookings stayed. Leadership wanted a broader commitment; the architect presented the scoring sheet, and the specific disagreement narrowed to the release-blocking row, which was resolved by showing the counted incidents. That is the method working: the argument became about one number instead of about philosophy.
Presenting the recommendation
As a developer
Presents the technical reasoning: coupling, scaling characteristics, deployment independence, and how the split would be sequenced. All correct, and it lands as a preference against a competing preference.
As an architect
Presents the decision as a trade with numbers attached: here is what services would buy in this specific system, here is what they cost per year in capacity, here is the evidence for each input, and here is the measurement that would change the recommendation. Stakeholders can disagree with a number in a way they cannot disagree with a diagram — and a disagreement about one number is a decision that can actually be made.
You run the method and the total is 52, but the organisation has 12 engineers and no platform capability. What do you recommend?RevealHide
A modular monolith, and the reasoning is that readiness is a gate rather than a criterion that averages with the others. A high signal score says services would solve a real problem; low readiness says the organisation would not survive operating them, and twelve engineers running eight services means nobody genuinely owns any of them and the on-call load falls on the same three people. The valuable part of the answer is what comes next: name the two or three highest-scoring signals, describe the cheapest way to address each inside the monolith — extracting the single worst-scaling component as an asynchronous worker often covers most of it — and state what would need to be true to revisit, typically headcount plus a platform capability plus a functioning on-call rotation. A recommendation without a path forward is just a refusal.
Key takeaways
- Default to a modular monolith; moving to services requires positive evidence for a specific property you need.
- Score four strong signals — differential scaling, counted release blocking, differential availability, runtime need — plus boundary clarity and consistency tolerance.
- Treat organisational readiness as a gate, not as a score to average in.
- Extract one component and measure before committing to a broader split.
- Record the numbers, the rejected alternatives and the revisit trigger, so the decision can be defended and revisited.