by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://media.babylovegrowth.ai/blog-images/organization-13731/1793458886496_Engineers-comparing-software-architecture-sketches.jpeg",
"@type": "ImageObject",
"caption": "Engineers comparing software architecture sketches"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "Microservices vs Monolith: How to Choose in 2026",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "Microservices vs monolith, and the modular monolith in between: how each works, what it costs, when to split, and how to decide without following the hype.",
"dateModified": "2026-11-02T00:00:00.000Z",
"datePublished": "2026-11-02T00:00:00.000Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"name": "Microservices vs Monolith: How to Choose in 2026",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

Microservices vs Monolith: How to Choose in 2026

Start with a monolith, or a well-structured modular monolith, unless you can name a specific problem that independent services would solve. Microservices pay off when separate teams need to deploy, scale and fail independently, and when you have the operational maturity to run a distributed system. Most products reach that point later than their roadmaps suggest.

That sounds like heresy in a decade that treated microservices as a mark of seriousness. It is closer to a correction. Architecture is a bet about the future of your organisation, and too many teams are building yesterday’s dreams: the architecture of a company they hope to become, paid for by the company they are.

Format-3

Make Your Product Decisions Count

Format-3 brings strategy, design and engineering together to create and scale digital products across industries.

Explore Format-3

TL;DR

• A monolith is one codebase and one deployable unit. Microservices split an application into small services, each tied to a business capability and deployable on its own.
• A modular monolith keeps one deployable unit but enforces internal boundaries. It is the sensible default for most new products.
• Microservices trade simplicity for independence: you gain deployment, scaling and fault isolation, and you take on network failures, distributed data and heavier operations.
• Split only when evidence points to a need: teams colliding, uneven scaling demand, or a part of the system that needs a different technology.
• If you migrate, do it in small increments and start with the modules where separation creates the most value.

Table of Contents

• What the two terms actually mean
• The third option: the modular monolith
• Side by side: where the real differences sit
• What you gain with microservices
• What you pay for them
• What a monolith gives you that people undervalue
• When to use microservices
• When a monolith or modular monolith is the better call
• How to migrate from a monolith to microservices
• A note on design and architecture
• Our perspective
• Working with a team that treats architecture as a product decision
• FAQ
• Sources

What the two terms actually mean

A monolith is a single application codebase and deployment unit. Its components share resources and are usually tightly coupled. Microservices decompose the application into small services, each responsible for one business capability and independently deployable through defined interfaces.

Microsoft’s architecture guidance adds the organisational detail: each microservice is a separate codebase owned by a small team, responsible for its own persistence and communicating with others through APIs. That last part matters. Microservices are as much a statement about who owns what as about how code is packaged.

A monolith is not, by definition, a mess. “Monolithic” describes how the thing ships, not how well it is written. A tidy monolith and a tangled one deploy the same way and behave very differently on a Tuesday afternoon when someone needs to change the billing logic.

The third option: the modular monolith

Most searches for this topic now include a third term, and for good reason. A modular monolith divides code into feature modules with interfaces and bounded contexts, all inside a single process. According to TechTarget, it keeps data consistent and communication simple, but it runs within one runtime.

The cleanest way to separate it from microservices is the deployment boundary. InfoQ frames it this way: modules in a modular monolith are modular at design time but deployed together, while microservices carry that modularity through to independent deployment.

Think of it as rehearsing the split without paying for it. If your module boundaries are right, you can later lift one out into a service. If they are wrong, you find out cheaply, with a refactor rather than a distributed outage.

Side by side: where the real differences sit

Oracle’s architecture documentation summarises the core contrasts across deployment, scaling, reliability and operating complexity. The table below uses that framing, with detail from the sources in each section.

Dimension: Deployment | Monolith: One unit, deployed whole | Modular monolith: One unit, deployed whole | Microservices: Each service deployed independently

Dimension: Scaling | Monolith: Scales as a unit | Modular monolith: Scales as a unit | Microservices: Each service scales on its own demand

Dimension: Data consistency | Monolith: Shared datastore, transactions | Modular monolith: Shared datastore, transactions | Microservices: Distributed, often eventual consistency

Dimension: Failure impact | Monolith: A component fault can affect everything | Modular monolith: Same runtime, but boundaries contain the damage in code | Microservices: A service failure may leave others available

Dimension: Technology choice | Monolith: One stack | Modular monolith: Largely one runtime | Microservices: Different stacks per service

Dimension: Operating load | Monolith: Low | Modular monolith: Low to moderate | Microservices: High, needs mature tooling

Dimension: Team fit | Monolith: Small to mid-sized teams | Modular monolith: Mid-sized teams with clear domains | Microservices: Many autonomous teams

None of these rows is a verdict. They are the shape of the trade.

What you gain with microservices

Independent deployment. A team can ship its service without coordinating a release with everyone else. AWS notes that in a monolith, one application and its dependencies are installed in one environment, whereas microservices are deployed as separate packages, commonly containerised.

Targeted scaling. Google Cloud explains that microservices can be scaled according to each service’s demand, unlike tightly coupled monolithic components that share resources. If search takes ten times the traffic of checkout, you scale search.

Resilience. The same Google Cloud guidance notes that the failure of one service does not necessarily affect the whole application. The word “necessarily” is doing real work there, as we will see below.

Organisational independence. Paulo Merson of Carnegie Mellon’s Software Engineering Institute frames microservices as an exchange. Teams gain deployability, reliability, scalability, modifiability and organisational independence, but take on harder deployment, testing, operations, performance, memory and security work.

Technology freedom. Different services can use different runtimes. TechTarget points out that a modular monolith generally cannot offer the same polyglot freedom, because its modules share one runtime.

What you pay for them

The costs arrive in places the architecture diagram does not show.

The network becomes part of your program. Martin Fowler observes that microservices give you independent deployment and strong module boundaries, but make programming harder because remote calls are slower and can fail. Oregon State University’s software engineering handbook makes the same point from the other side: monolith components communicate through fast, lightweight direct calls, while microservices often communicate over a network, adding communication costs and potential security risks.

Data gets harder. InfoQ notes that colocated monolithic modules can use transactions and referential integrity from a shared relational datastore, while microservices cross network boundaries and lose that simplicity. Fowler names the consequence: eventual consistency, because strong consistency across a distributed system is difficult to maintain.

Testing and debugging stretch. The Oregon State handbook adds that distributed end-to-end tests are harder to set up and run. AWS describes microservices as harder to debug, and as needing more planning, since you must identify independent functions and design consistent APIs before implementation.

Operations multiply. Red Hat lists the extras: per-service runtimes and data storage, separate development and testing processes, deployment scripts and network-access configuration. Google Cloud also warns of infrastructure complexity and hidden cloud costs. Oracle’s documentation says microservices require rapid provisioning, basic monitoring and rapid deployment to work at all.

None of this is an argument against microservices. It is the price list. Teams that read it before buying tend to be happy with what they bought.

What a monolith gives you that people undervalue

AWS says monoliths are easier to start because they need less upfront planning, and easier to deploy and debug. That speed matters most when you do not yet know what you are building.

There is a quieter benefit. In an early product, the boundaries between capabilities are guesses. InfoQ argues that complex domains with bounded volumes favour a modular monolith because the boundaries can still evolve. Move a boundary inside a codebase and you edit code. Move one between services and you renegotiate contracts, data ownership and release schedules.

The monolith’s weak spots are real: a change can affect the whole application, and scaling can waste resources because you scale everything to satisfy one hot path. The question is whether you have that problem yet, or only expect to.

When to use microservices

The Software Engineering Guide offers a useful default: start with a modular monolith and split only when evidence shows a need for independent scaling, a different deployment cadence, fault isolation or a different technology. That list is a good test. A reason that does not map to one of those four is probably taste.

Microservices are a strong fit when:

1. Multiple independent teams need to ship at their own pace and keep stepping on each other in a shared codebase.
2. Parts of the system have sharply different load profiles, so scaling them together burns money.
3. A component needs a different runtime or technology, such as a machine-learning service beside a transactional core.
4. You are operating at internet scale in a domain you already understand. InfoQ suggests simpler domains at that scale may justify microservices once service responsibilities are sufficiently understood.
5. Your platform makes services cheap. TechTarget notes a modular monolith may be a poor fit when service templates make microservices inexpensive in a mature environment, or when scale and operational expertise already justify them.

The maturity point deserves emphasis. The Software Engineering Guide says microservices need mature CI/CD, automated infrastructure, distributed tracing, service discovery and an on-call culture, and that without them they can multiply failure modes. That is why “a failure in one service does not necessarily affect the others” is a promise that has to be earned.

When a monolith or modular monolith is the better call

TechTarget identifies greenfield systems, low-to-moderate scale products, non-complex business platforms and oversized legacy applications as natural homes for a modular monolith. In practice that covers a large share of the products we meet: a healthcare scheduling platform, a media subscription service, a SaaS dashboard finding its market.

A quick self-check:

• Is your team small enough to share one codebase without constant collisions?
• Do you still change your mind about what the product does every quarter?
• Is your biggest risk finding product-market fit rather than handling traffic?
• Would a platform engineer be a new hire, not an existing role?

If you answered yes to most of these, a modular monolith will probably get you further, faster, with fewer 3 a.m. pages.

How to migrate from a monolith to microservices

If the evidence does say split, resist the big rewrite. Chris Richardson’s guidance recommends making the most of the monolith first, adopting microservices for the right reasons, getting business support, migrating incrementally, understanding your starting point and migrating high-value modules first.

A practical sequence:

1. Make the monolith modular. Draw the boundaries inside the codebase and enforce them. If you cannot keep modules apart in one process, a network will not help.
2. Pick the first candidate by value, not elegance. Look for the part where teams collide, change is frequent or the component is fragile.
3. Build the platform before the second service. Deployment pipelines, tracing, monitoring and service discovery come first.
4. Separate the data deliberately. Decide who owns each table, and accept where eventual consistency will replace a transaction.
5. Extract in small steps and measure. Did deployment frequency rise? Did incidents fall? If not, stop and find out why.

The discipline here is the same one we apply to product work generally: products do not scale, systems do. An architecture is only as good as the system of people, tooling and decisions around it.

A note on design and architecture

Architecture debates tend to happen far from the person using the product, yet they surface in the interface. A slow, inconsistent screen can be the visible symptom of a chatty set of services. A clean, fast experience often reflects a well-drawn boundary. In our work on an AI-powered healthcare product, the shape of the system and the shape of the experience had to be designed together, because clinicians feel latency and inconsistency long before they care what runs underneath.

Our perspective

Every few years the industry crowns an architecture, and every few years a generation of teams inherits the bill. We have watched ambitious startups adopt a dozen services before they had a dozen customers, and we have watched enterprises stay in a tangled monolith long after it stopped serving them. Both are versions of the same mistake: choosing an architecture for the story it tells rather than the problem it solves.

Working with a team that treats architecture as a product decision

If you are weighing this choice for a web platform, native app or AI-enabled product, we can help you frame it before it hardens into code. Our digital product services cover discovery, design sprints, full-stack development and product growth, and our AI product design and development work covers the intelligent features that increasingly stress an architecture. Pricing is scoped per engagement, so the first step is a conversation about your product.

FAQ

Is a modular monolith better than microservices?

Not universally, but it is the better starting point for most new products. It keeps data consistent and communication simple while keeping operational costs below those of running tens or hundreds of services. Microservices become the better choice when independent scaling, deployment or technology needs are proven.

What is the main downside of microservices?

Complexity moves from the code into the system around it. You take on network failures, distributed data, harder testing and heavier operations, as the SEI’s analysis of the trade-off lays out. Teams with strong automation and monitoring absorb this far better than those without.

How big should a team be before microservices make sense?

Team size alone does not decide it. The signal is when several teams need to release independently and keep blocking each other in one codebase. If one small team owns everything, services mostly add overhead.

Can you start with a monolith and move to microservices later?

Yes, and that is the path many experienced practitioners recommend. Build the monolith with enforced module boundaries, then extract the highest-value modules incrementally, as Richardson’s migration principles advise.

Sources

• Monolithic vs Microservices: Difference Between Software Architectures (AWS)
• Microservices architecture design (Microsoft Learn)
• Understanding the modular monolith and its ideal use cases (TechTarget)
• Understanding the modular monolith, use cases (TechTarget)
• In Defence of the Monolith, Part 1 (InfoQ)
• Learn About the Microservices Architecture (Oracle)
• Monolith versus Microservice Architectures (Oregon State University)
• What Is Microservices Architecture? (Google Cloud)
• The disadvantages vs. benefits of microservices (Red Hat)
• Microservices Guide (Martin Fowler)
• Microservices Beyond the Hype (Carnegie Mellon SEI)
• Architectural styles and patterns (Software Engineering Guide)
• Ten principles for refactoring to microservices (Chris Richardson)

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms