Modular monolith vs microservices: what a small team should build first

You are building something, maybe with an AI coding tool, and someone says "you should really use microservices." This page is the sober version of that conversation. I read the architecture writers who coined these terms, plus Microsoft's and Amazon's own docs, on 3 October 2026.

What is a monolith, and is it a bad word?

A monolith is an application deployed as one unit. Your code, your screens and your logic ship together and usually share one database. It is not an insult. The sources treat it as the normal starting point, and the one that most real apps never need to leave.

Martin Fowler's article defines it as "a single logical executable." A change to one corner means building and shipping the whole thing. Scaling means running more copies of the whole thing.

Chris Richardson lists the upside on microservices.io. Everything talks by local calls, which are "typically more efficient since all communication is local." An action that touches two areas can usually be "implemented as ACID transactions." ACID is the database promise that a change either fully happens or does not happen at all. If you want the basics of the database side, see what a database is.

He also lists the downsides. A big monolith is hard to understand. Teams step on each other because they share one codebase. The pipeline that tests and ships it gets slow. And he adds: "These drawbacks become more severe as the application grows in size and complexity and the number of teams developing it increases."

Notice what that last sentence is about: size and number of teams. A small team with one product has few of those problems.

What is a modular monolith?

A modular monolith is still one app and one deploy, but the code is organized by business area rather than by technical layer. Instead of folders named web, logic and database, you have folders named customers, orders and notifications. Each area owns its own code.

This is Richardson's description. In his series on microservices.io, he starts with the classic layout, three technical layers, and notes it works for small apps but gets painful as developers are added. His alternative is to "structure it around the business domains rather than the technical layers, the so-called modular monolith architectural style."

In his example, the project has a main entry point plus customers, orders and notifications folders, and each one has its own web, domain and persistence parts. The payoff he names is team autonomy, "since each team is working on a distinct part of the code base." A change to one area should, "hopefully," only need that area's tests.

One honest note. "Modular monolith" has no official standard. Richardson's own series has a later part titled "no such thing as a modular monolith?" So treat it as a description of a habit, not a product: keep the walls between areas real, and have areas talk through a small front door instead of reaching into each other's data.

What are microservices?

Microservices split an application into small services that are deployed separately and talk to each other over a network. Each service is usually owned by one small team and keeps its own data. You can update one without redeploying the rest.

Microsoft's architecture guide lists the benefits: independent deployment, fault isolation, scaling one service on its own, and small focused teams. A service "should be small enough that a single feature team can build, test, and deploy it."

Those are real. They also assume you have the teams, the tooling and the skills. Microsoft's own list of challenges starts with this sentence: "Each service is simpler, but the entire system as a whole is more complex." It then names service discovery, data consistency, versioning, correlated logging across services, and a team skill set. It adds that success requires "a mature DevOps culture."

If a network between your parts sounds like an API, it is. Every service boundary is an API you now have to keep stable. Our explainer on what an API is covers that idea.

What does Martin Fowler say a small team should do?

Start with one app and keep it modular. In 2015 Fowler wrote that you should not consider microservices "unless you have a system that's too complex to manage as a monolith." He said most systems should be a single monolith, with good modularity inside it.

Two of his short essays carry the argument. In Microservice Premium, he says microservices bring "automated deployment, monitoring, dealing with failure, eventual consistency, and other factors that a distributed system introduces." That is the premium you pay. His summary: "if you can keep your system simple enough to avoid the need for microservices: do."

What does "too complex" mean? He lists sources of complexity: large teams, multi-tenancy, many user interaction models, business functions that must evolve independently, and scaling. Then he names the biggest one: "people finding they have a monolith that's too big to modify and deploy." Size, in other words.

In Monolith First, he reports a pattern he kept hearing: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up." And the reverse: systems "built as a microservice system from scratch" often "ended up in serious trouble." His reason is boundaries. Services only work with stable boundaries, and "even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning." Moving code between services is much harder than moving it inside one app.

Fowler is also careful. He says the evidence is thin and his advice "must be seen as tentative." He admits that building a monolith modular enough to split later takes discipline, and that he would be more comfortable if he had heard "a decent number of stories where it worked out that way." The opposing view exists too: starting with services gets a team used to working that way. He still concludes you should not start with microservices without experience building them.

These essays are 11 years old. They are still the most cited statement of the argument, and Richardson's and Microsoft's current pages say the same kind of thing about cost. They are opinion from experienced people, not a measurement.

When do microservices actually pay off?

They pay off when one codebase has become the bottleneck: many teams blocked on each other, releases that cannot go out independently, or one part that needs very different scaling or technology. If none of that is hurting yet, the cost comes first and the benefit later.

Put the sources together and the signals look like this:

• Many teams in one codebase. Richardson's drawbacks list is about teams contributing "to the same code base" and coordinating constantly.
• A slow shared pipeline. One huge app that takes too long to build and test.
• Parts with different needs. One area needs to scale alone, or needs another language or security level.
• A monolith too big to change safely. Fowler's "biggest factor."

Fowler adds a footnote worth remembering: team shape matters. The size of a service varies widely. He has seen "a team of 60 with 20 services" and "a team of 4 with 200 services." So there is no magic head-count number. I will not give you one, because none of these sources does.

And Richardson's own first rule, from his modular monolith series: "The first rule of migrating to microservices is don't. Instead, you should make the most of your monolith."

If you are weighing what hosting costs along the way, our guides to what hosting is and what it costs and why an AWS bill gets so high are worth a look. More moving parts often means more line items.

What did Amazon Prime Video do?

Prime Video's video quality team rebuilt one internal tool from separate serverless pieces into a single process, and reported its infrastructure cost fell by over 90%. The tool watches live streams for glitches. It is not the whole Prime Video service.

Amazon's engineer Marcin Kolny wrote the post on 22 March 2023. The first version used AWS Step Functions and Lambda, and Amazon calls it "a good choice for building the service quickly." It hit "a hard scaling limit at around 5% of the expected load." Two things cost the most. The orchestration made multiple state transitions for every second of a stream, and Step Functions charges per transition. And video frames were passed between pieces through S3 storage, where "the high number of Tier-1 calls" was expensive.

The fix: "we packed all of the components into a single process," so the frames moved in memory. Amazon says the components stayed the same, so much of the code was reused. The result: "Moving our service to a monolith reduced our infrastructure cost by over 90%."

Read this with care. It is one tool with a very particular workload: work on every second of a video stream. Amazon did not publish dollar amounts. The pieces were serverless functions billed per step, not a typical small-team web app. Amazon also says the monolith now scales vertically inside one instance, and when it outgrew one instance they "cloned the service multiple times" with different parts of the work.

Amazon's own conclusion is the useful part: "Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis."

What is a saga, and why do microservices need one?

When two services each own a database, one business action that touches both cannot be one database transaction. A saga is the workaround: a chain of small local transactions, where each step triggers the next, and a failed step triggers "compensating" steps that undo the earlier ones.

Richardson's example is an online store with a customer credit limit. Orders and Customers are in different databases owned by different services, so "the application cannot simply use a local ACID transaction." His definition: "A saga is a sequence of local transactions." Each one updates its own database and publishes a message to trigger the next. If one breaks a business rule, the saga runs compensating transactions that undo the earlier changes.

Walk through it. The Order service saves the order as PENDING. Customers tries to reserve credit. If it works, Orders marks the order approved. If the credit limit is exceeded, Orders runs the undo step and rejects the pending order.

There are two ways to run a saga, per Richardson and Microsoft. In choreography, each service reacts to events published by the others, with no boss. In orchestration, one orchestrator tells each service what to do next. Microsoft says choreography suits "simple workflows that have few services," while orchestration is "better suited for complex workflows," at the cost of a central point of failure.

What does a saga cost you?

A saga costs you automatic rollback and isolation. A normal database transaction undoes itself and hides half-finished work from other users. In a saga, a developer writes every undo step, and other requests can see in-between states. The sources are blunt about this.

Richardson lists the drawbacks as "Lack of automatic rollback" and "Lack of isolation (the 'I' in ACID)." AWS's guidance says: "The saga pattern is difficult to debug and its complexity increases with the number of microservices." Microsoft adds that "Compensating transactions might not always succeed, which can leave the system in an inconsistent state." It names the anomalies that can show up, lost updates and dirty reads, and countermeasures such as a "semantic lock," a flag that says an update is in progress.

Microsoft also gives a case where a saga is a poor fit: when "Transactions are tightly coupled." That is a useful test for any split. If two pieces must always change together, they probably belong in the same service, or in the same modular monolith, where one transaction does the job for free.

This is the sharpest argument for the modular monolith. Inside one app and one database, "create the order and reserve the credit" is a single transaction. There is nothing to compensate.

How should a small team decide?

Start with a modular monolith. Draw clean walls between business areas now, so a split later is possible. Move to services only when a specific, named problem shows up and you can say which service fixes it. A trend or an interview question is not a reason.

A decision checklist that follows from the sources:

1. Do you have several teams blocked on one codebase? If not, you do not have the problem microservices solve.
2. Can you name the boundaries? Fowler warns that guessing boundaries early is hard even for experts. A monolith lets you find them cheaply.
3. Will an action need two services to change data together? If yes, you are signing up for sagas, undo steps and debugging them.
4. Do you have deployment automation, monitoring and tracing? Microsoft says you need a mature DevOps culture.
5. Is one part under very different load, language or security needs? That is a reason to split that one part, not everything.

Fowler's own footnote describes a gentle path: peel services off at the edges while the monolith stays at the center. Another is to start with a couple of big, coarse services and split later. Both come from people who have watched it done.

If you are shipping an AI-built app, our guide to how to ship a vibe-coded app covers the basics first. This site, for the record, is one Next.js app deployed to Cloudflare Workers, which is a single deployable unit. That is a plain fact about us, not a claim that it is the right answer for you.