Written by:
Last Published:
20 October 2026
•
.webp)
The microservices vs monolith question is usually framed as a fight. Pick a side, defend it, hire accordingly. That framing is where most expensive mistakes start.
The honest answer sits on a spectrum. At one end, we have a single deployable application. But at the other, many independently deployed services. In the middle, the modular monolith, which gets far less attention than it deserves. Where you land depends on a handful of criteria, and most of them have little to do with technology.
This guide gives you a decision matrix, the failure patterns that appear when teams choose badly, a route for moving between options and a verdict for startups, scale-ups and enterprises. If you have already decided on microservices and want the how, our guide to microservices best practices covers it. This one covers the decision itself.
What is the short answer to the microservices vs monolith question?
For most new products, start with a modular monolith. Extract a service only when you can name a concrete driver: independent deployment, a divergent scaling profile or a hard isolation requirement. Make sure you can run a distributed system before you build one. Score your own case with the Imaginary Cloud Architecture Decision Matrix below.
The debate keeps returning because architecture is expensive to reverse and most teams decide without a structured method. In our survey of 100+ engineering leaders at QCon London 2026, 75 per cent said they make critical architecture decisions without a structured financial or strategic framework. That figure adds up the three answers with no structured approach: capacity-based (32 per cent), informal estimates (29 per cent) and ad hoc (14 per cent).
For a CEO or CFO the stakes are plain. Architecture decides how fast you ship, what each release costs and how much you spend before a feature earns anything. The same survey found that 43 per cent named monolithic or legacy systems as the main factor limiting their ability to scale, the largest single barrier reported. Note the wording. That is a finding about neglected legacy, not a verdict on every monolith.
And the public interest varies a lot. It tends to spike, probably around launches, conferences and big engineering write-ups, then fade. So the urgency does not come from fashion. It comes from the decision itself, which every growing product has to make, or remake. Treat it as a decision you will revisit.
The real choice is a spectrum with three points: a classic monolith (one codebase, one deployment), a modular monolith (one deployment, strict internal boundaries) and microservices (many independently deployed services). Each trades simplicity against independence. The right point depends on your team, your domain maturity and your operational capability, not on what large tech companies do.
Think of a restaurant kitchen. A classic monolith is one big room with a single counter: everyone cooks together, and it is wonderfully quick until the pastry flour ends up in the fish. A modular monolith is the same room with proper stations (grill, cold, pastry), each with its own fridge and one rule: nobody reaches into another station's fridge. Microservices are separate food stalls, each with its own kitchen, supplier and licence.
Is the street of stalls always better than the kitchen? No. Martin Fowler observed that almost every successful microservices story began as a monolith that grew too big, while systems built as microservices from day one often ran into serious trouble. Stefan Tilkov argued the opposite: a monolith's parts tend to become so tightly coupled that splitting them later is very hard. Both are right about something, which is why the decision needs criteria.
Sam Newman, who wrote the book on moving to microservices, has said that they should not be the default choice. Distribution is a cost you pay every day, so you need a concrete reason to pay it.
Score your situation against eight criteria, each of which favours a different point on the spectrum. If most answers land in one column, that is your starting architecture. If they scatter, begin with a modular monolith and mark the likely extraction candidates.
Two terms recur below. Observability is the ability to understand what a system is doing from the data it emits (logs, metrics and traces). Platform engineering is the work of building the internal tooling and standard routes that let product teams ship and run services without reinventing infrastructure each time.
| Criterion | Classic monolith | Modular monolith | Microservices |
|---|---|---|---|
| Team size and structure | One small team with shared context | Several teams that can coordinate releases | Many teams that need separate release cadences |
| Independent deployment | Not needed | Rarely needed, one release train is fine | A hard requirement for at least some components |
| Scaling profile | Uniform load | Mostly uniform, one or two hot spots | Components with genuinely different needs |
| Operational maturity | Basic CI/CD is enough | Solid CI/CD and test discipline | Strong observability, automation and a platform team |
| Fault and compliance isolation | One failure domain is acceptable | Isolation handled inside the code | Failures or regulated data must be physically separated |
| Domain clarity | Still discovering the product | Boundaries emerging, not yet proven | Boundaries stable and proven in production |
| Time to value | Fastest to a first release | Slightly slower start, then fast | Slowest start: tooling and platform come first |
| Cost profile | Lowest build, run and people cost | Low run cost, moderate discipline cost | Highest build, run and people cost, repaid where independence matters |
A word of caution on team size. Rules of thumb run from fewer than ten engineers to fewer than a hundred, and they contradict each other. Treat them as heuristics. What decides the matter is whether your teams can release independently without stepping on each other, and whether you can operate a distributed system once you have one.
The evidence is mixed, as it should be. One 2026 empirical comparison of an e-commerce application found that at 100 concurrent users the microservices version delivered 5.4 per cent more throughput and 39 per cent lower p95 latency than the monolith, with the two roughly level at 50 users. The authors stress that microservices introduce service-specific failure modes, and that the results apply to that one deployment. For example, Amazon's Prime Video team moved one monitoring workload from a distributed, serverless design to a single-process application and reported a 90 per cent reduction in operational costs, as InfoQ reported in 2023. Note the scope: one workload, not a company-wide retreat.
This walk-through is a composite, not a client story. Imagine a B2B platform with twenty engineers in three teams. Deployments are weekly and mostly painless. One component, a document-processing job, spikes hard at month end while everything else stays flat. The team has solid CI/CD but only basic monitoring, and the domain is still shifting.
Run it through the matrix. Team structure, independent deployment, operational maturity and domain clarity all point to a modular monolith. The scaling profile shows one hot spot, a candidate for extraction later. The result is a modular monolith now, with the document processor marked as the first extraction candidate and written-down triggers for moving it, such as release conflicts between teams or sustained cost from over-provisioning the whole application.
A modular monolith is one deployable application organised into well-defined modules with enforced boundaries. Modules talk through explicit interfaces, never through each other's database tables. You keep the simplicity of one deployment and gain much of the clarity of services, plus a clean path to extract a module later if a real driver appears.
The boundaries do the heavy lifting. If modules reach into one another's data, you have a monolith with nicer folder names, and it will degrade into a tangle over time.
Why does this matter for the decision? Because it lets you learn where the seams belong before you pay to cement them in the network. Microservices.io is blunt on the point: the monolithic architecture is not an anti-pattern, and if you outgrow it you can refactor incrementally using the strangler fig pattern (routing traffic from old code to new components bit by bit, until the old code can be switched off). Newman has gone further, suggesting many organisations would be better off with a modular monolith than with microservices.
It is not free. A single codebase can get slow to build and test, which is why build-time coupling needs design attention as the system grows.
Cost is more than the cloud bill. You must count with infrastructure, tooling, people, the cost of coordinating change and the cost of delay. Microservices raise the first three and can lower the fourth. A monolith does the reverse. Time to value follows the same pattern: fastest to start with a monolith, slowest with microservices.
Only 11 per cent of the leaders in our QCon London survey named cloud or infrastructure cost as their main architecture challenge. Most of the cost sits in structure: complexity, deferred architectural debt and slower delivery. That is why a cost model built only on hosting fees points the wrong way.
Calendar time is the executive question. In our Sedna spotlight, the phased route (optimise, pilot, migrate) took about six months with two embedded specialists. Plan in quarters, not sprints, and put a go or no-go gate at each stage.
Your numbers depend on your load, your team and your vendor contracts. Model them early, with finance in the room.
Some architecture stories come down to a handful of repeated mistakes. Naming them helps. Each pattern below is a sign that the decision, or the execution of it, has gone wrong.
Services that must be deployed together are a monolith with a network in the middle. For example, if you have a full-time release coordination manager, you probably have one. You pay the operational cost of microservices and collect none of the independence.
Several services reading and writing the same schema are coupled at the data layer, whatever the diagrams say. One migration breaks three teams. The fix is ownership: each service owns its data and exposes it through an interface.
Service A calls B, which calls C, which calls D. If D is down, everything is down, exactly as in a monolith, only slower. A systematic review of resilience in microservices lists the usual suspects: timeouts, dependency outages and retry storms.
Splitting by technical layer, with a front-end service and a back-end service, creates coupling instead of removing it. Boundaries should follow business capabilities. Domain-driven design (an approach that models software around the business domain and marks where each model applies with bounded contexts) is the usual toolkit, and Microsoft's guidance on identifying microservice boundaries is a good place to start.
Fifty tiny services with no tracing, no automation and no on-call maturity is a recipe for slow debugging and slower releases. Microservices demand investment in observability and platform engineering. If you cannot fund that, you cannot afford the architecture.
If module boundaries exist only in a slide deck, the codebase will quietly return to a big ball of mud. Enforce boundaries with tooling and code review, and treat violations as defects.
Move one module at a time. Put a routing layer in front of the system, extract a single module that has a concrete driver, run old and new in parallel, shift traffic gradually and retire the old code. Treat each step as a gate. If the evidence is weak, stop and keep the module where it is.
AWS prescriptive guidance describes the pattern in three moves: transform, coexist, eliminate. In practice that looks like this:
The same route works in reverse. Consolidating over-split services into a modular monolith is a legitimate move, and Prime Video's example shows why. For a wider view on when to migrate, refactor or rebuild, see our guide to legacy system modernisation.
Containers are a packaging choice, not an architecture. You can containerise a monolith, a modular monolith or a fleet of services. What microservices add is the need to orchestrate many containers, which is where tools such as Kubernetes and a platform team come in. Our guide to what Kubernetes is covers the orchestration routes.
Serverless is another option, with limits. The Sedna spotlight names three: a 15-minute execution cap, consistently high-volume workloads that can be cheaper on dedicated infrastructure, and highly stateful processes. Check your workload against them before you commit.
Systems tend to mirror the teams that build them, which is Conway's Law. Fowler's note on it ties service boundaries to team structure. So ask the organisation question first. Can your teams own a slice end to end, release without asking permission and carry their own on-call? If not, services will give you more meetings across a network, not independence.
Use this as a starting position, not a rule. The right answer to the microservices vs monolith question changes as you grow, so reassess when your answers to the matrix change.
Start with a modular monolith, or a plain monolith if the team is tiny and the product is still finding its shape. Speed of learning matters more than theoretical scale. Revisit when separate teams block each other's releases, or when one component's load profile diverges sharply from the rest.
The executive view: being wrong costs a few quarters of extraction work, while premature microservices cost you a platform you built before you had customers.
Keep the modular monolith as the core and extract services selectively, where there is a concrete driver: independent scaling, separate team ownership or a different deployment cadence. Extract one module, run it in production, learn what it costs, then decide on the next.
The executive view: ask for the driver, the owner and the expected payback of every extraction, in that order.
Expect a portfolio, not a single answer. Domains with stable boundaries, autonomous teams and isolation requirements are strong candidates for microservices. Others are better served by a modular monolith, or by a well-kept legacy system that works. Fund the platform first.
The executive view: the biggest risk is rarely the architecture, it is the decision process. With 75 per cent of organisations deciding without a structured framework, write the decision and its triggers down.
Neither project was framed as microservices versus monolith, and we are not claiming otherwise. We cite them for what they show about the criteria in the matrix: cost, ownership, isolation and sequencing.
Sedna. The Sedna spotlight describes a maritime communications company that cut what it spent on vendor licensing and related infrastructure by 80 per cent, by replacing Tray.io. The route matters more than the number. Large, vendor-hosted workflow configurations were rebuilt as small functions orchestrated with AWS Step Functions. That is not a textbook microservices migration (these are serverless functions, not long-running services), but the decision logic is the one in our matrix. The team optimised first, piloted before migrating and kept the old platform running for two weeks as a safety net.
TrustPortal. The TrustPortal spotlight reports a 40 to 50 per cent reduction in operations costs. Its most useful lesson for this decision is a refusal. According to the spotlight, a regulated core stayed on legacy infrastructure for regulatory and audit reasons, about 70 per cent of the estate moved to the cloud, and legacy and cloud ran side by side during the transition. That is the spectrum in action: one organisation, different answers for different parts, each justified by risk and a concrete driver.
What the two share is the order of operations. Both started by counting what the current set-up was costing, and both ran old and new side by side before committing.
Neither is better in the abstract. The microservices vs monolith choice depends on team structure, scaling needs, operational maturity and how well you understand your domain. For most new products the sensible start is a monolith or modular monolith, with services extracted only when a concrete driver appears.
A modular monolith is a single deployable application split into well-defined modules with enforced boundaries and explicit interfaces. It keeps one deployment and one operational footprint while giving you the structure to extract services later, if and when a concrete need appears.
No. A monolith is a legitimate choice, particularly for early products and small teams. Problems arise when it has no internal structure, or when the organisation outgrows it and keeps adding coordination cost. The architecture is not the enemy. Unmanaged complexity is.
Usually not. A small team that shares context and releases together gains little from independent deployment and pays the full operational cost of a distributed system. Start with a modular monolith, keep boundaries clean and extract a service only when releases start colliding or one component's load profile diverges sharply.
Look for concrete symptoms: teams blocking each other's releases, deployments that need coordination meetings, one component needing very different scaling from the rest, or isolation requirements for failures or regulated data. Vague unease is not a sign. If you cannot name the driver, tighten the module boundaries first.
It depends on the workload. In-process calls avoid network latency and network failure, which favours a monolith for chatty logic. Independent scaling can favour services under uneven heavy load. One 2026 empirical study found microservices held higher throughput under load, while Prime Video cut costs by moving one pipeline to a single process.
Expect higher infrastructure, tooling and people costs with microservices, offset only where independent scaling or deployment creates value. Count five lines: infrastructure, tooling, people, the cost of coordinating change and the cost of delay. There is no honest single figure, because the answer depends on your load, team and contracts.
Move one module at a time using the strangler fig pattern. Route traffic through a facade, extract a module with a clear driver, run old and new in parallel, shift traffic gradually and retire the old code. Optimise what you have first, and put a go or no-go gate after the pilot.
A distributed monolith is a system deployed as separate services that are still tightly coupled. Services must be released together, share databases or depend on long synchronous call chains. It carries the operational cost of microservices without their independence, which is why it is often called the worst of both worlds.
The microservices vs monolith question was never really about picking a camp. It is how much independence you need, how much complexity you can run, and how well you understand your own domain. Score yourself against the matrix, start where the answers point, and keep the option to move.
Two takeaways. Default to the simplest architecture that meets your real constraints, and make every extra service earn its place with a concrete driver. And if you have already chosen microservices, the next step is doing them well, which our guide to microservices best practices covers.
Weighing up an architecture decision of your own? Our team can help you apply the Imaginary Cloud Architecture Decision Matrix to your product, your teams and your constraints. Talk to us about architecture consulting.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
