A new product team gathers on day one and someone says, "Let's do microservices, it's how the serious companies build." It sounds responsible. It is usually a mistake. The two architectures are not a question of modern versus dated; they are a question of what you are optimising for, and most teams reach for the harder one long before they have the problem it solves.

The quick version

  • A monolith is one application, all the features built, deployed and run as a single unit. A microservices architecture splits the same product into many small services that run separately and talk over the network.
  • The real trade-off is not speed of code, it is independence: microservices let separate teams build, deploy and scale their piece without waiting for each other, at the cost of a lot more operational complexity (networks, failures, data spread across services).
  • Microservices are an organisational tool as much as a technical one. If you have one team, you mostly get the costs and few of the benefits.
  • The widely-respected advice is "monolith first", start as one well-organised application, and split out services only when a real strain (team size, scaling, deployment friction) tells you where the seams are.

The idea in depth

A monolith gets a bad name it half deserves. The word conjures a tangled, un-deployable block of code, but that is a description of a badly built monolith, not of the pattern. A clean monolith is simply one codebase, one deployment, one database, the whole product running together. Everything is one function call away, so it is easy to develop, easy to test end to end, and easy to deploy: you ship one thing. Sam Newman, author of Building Microservices, makes the point bluntly, the monolith is a perfectly reasonable default, and treating it as something to be ashamed of is how teams talk themselves into complexity they cannot afford (see his GOTO 2020 conversation with Martin Fowler, linked below).

Microservices break that single application into independently deployable services, each owning a slice of the product and a slice of the data, communicating over the network. The motivation that actually holds up is independence. As Martin Fowler and James Lewis put it in their foundational 2014 article, the style organises software as a suite of small services "built around business capabilities and independently deployable." That last phrase is the whole prize: a payments team can ship a fix at 2pm without a search team's code being anywhere near the release. So the move is to be honest about whether you have several teams that genuinely need to move at different speeds, because that, not raw performance, is what microservices buy.

An honest limitation. Independence is not free, and the bill arrives in the places a diagram hides. The moment two services talk over a network, you inherit a category of problem a monolith never had: the network can be slow or down, a call can half-succeed, data that used to live in one consistent database now lives in several that can disagree. Newman calls the worst-of-both-worlds outcome a "distributed monolith", services split apart on paper but so entangled that you must deploy them together anyway, paying the full operational cost while getting none of the independence. Splitting a system does not remove complexity; it moves it from inside the code (where a compiler can catch mistakes) out into the running system (where only production can).

flowchart TB
  subgraph M["Monolith, one deployable unit"]
    A(["UI"]) --> B(["Orders · Payments · Search
all in one process"])
    B --> C(["One database"])
  end
  subgraph S["Microservices, independent units"]
    D(["Orders service"]) --> DD(["Orders DB"])
    E(["Payments service"]) --> ED(["Payments DB"])
    F(["Search service"]) --> FD(["Search DB"])
    D -. network .-> E
    D -. network .-> F
  end
The same product, two shapes: one process and one database, versus many services that own their own data and talk over the network. Leaders Loop

Why this is really about your org chart

The decisive idea predates microservices by half a century. In April 1968, computer scientist Melvin Conway published "How Do Committees Invent?" in Datamation, with a claim now known as Conway's Law: "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations." In plain terms, your software ends up shaped like your teams. Four teams that barely speak will build four chunks of software that barely talk to each other, whatever the architecture diagram says.

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.", Melvin Conway, 1968

This reframes the whole decision. Microservices work when your service boundaries match your team boundaries, each team owns its service, its data and its deployment, and they coordinate through stable interfaces instead of shared code. If you have one team of five, there are no communication structures to mirror, so you get the operational tax of distribution with none of the autonomy it is meant to deliver. So the move is to draw your team map before your service map. If the teams that would own the services do not yet exist, the architecture is solving a problem you do not have.

The catch. Conway's Law is an observation about tendencies, not a precise law you can plug numbers into, and people sometimes overreach with "Inverse Conway," the idea that you can reshape teams to force a desired architecture. Reorganising humans is far costlier and slower than refactoring code, and a reorg done purely to chase a diagram tends to break things the old structure quietly held together. Use Conway's Law as a lens for "do our teams and our intended boundaries actually line up?", not as a licence to rearrange people on a whim.

"Monolith first", the default the evidence supports

The most useful practical guidance is also the least fashionable. In his 2015 essay "MonolithFirst," Martin Fowler reported a consistent pattern from the field: "almost all the successful microservice stories have started with a monolith that got too big and was broken up," while systems "built as a microservice system from scratch" tended to end "in serious trouble." The reason is boundaries. Microservices only pay off when the lines between services are drawn in the right places, and at the start of a product, when you understand the domain least, you are worst-placed to draw them. Get a boundary wrong and you have welded a mistake across a network, where it is painful to move.

So the responsible default is to begin as a single, well-modularised application: clean internal boundaries, separated by business capability, but deployed as one unit. You move fast while you are still learning what the product is. Then, when a genuine strain appears, one part needs to scale on its own, one team is constantly blocked behind another's releases, you extract that part into its own service along a seam the monolith has already revealed. The architecture follows the evidence instead of guessing ahead of it. This is not a fringe view: it is the converging advice of the people who wrote the canonical books on microservices, who spend much of their time talking teams out of premature splits.

Where it bends. "Monolith first" is a strong default, not an absolute. Fowler himself notes the exception: a team that has built this kind of system before, in a domain they know well, may legitimately start with services because they can already see the boundaries. And famously over-large monoliths can become so entangled that carving them up later is brutal. The point is not "monoliths always win", it is that the cost of starting simple and splitting later is usually far lower than the cost of starting distributed and being wrong.

A worked example

Take a fictional retail startup, call it Greenrows, building an online grocery service. (Illustrative throughout; this is a teaching example, not a real company.) Five engineers, one product, racing to launch before the next funding round.

The temptation is to copy the architecture of a company a thousand times their size: a service for the catalogue, one for the cart, one for checkout, one for delivery scheduling, each in its own repository with its own database. On a whiteboard it looks grown-up. In practice, those five engineers now spend their days on plumbing, wiring up the calls between services, debugging why the cart shows an item the catalogue service already removed, standing up five deployment pipelines instead of one. A change to checkout, which used to be one edit, now ripples across three services that must be released in lockstep. They have built the distributed monolith: all the cost of distribution, none of the independence, because there is only one team.

flowchart TD
  A(["5 engineers, 1 product,
racing to launch"]) --> B{"Split into services
on day one?"}
  B -->|"Yes, copy the big-co diagram"| C(["Distributed monolith:
plumbing, lockstep deploys,
data that disagrees"])
  B -->|"No, one modular monolith"| D(["Ship the product;
learn where the seams are"])
  D --> E{"A real strain appears?
(scaling / a blocked team)"}
  E -->|"Not yet"| D
  E -->|"Yes, checkout needs
to scale on Black Friday"| F(["Extract just that service
along a known seam"])
The cheap path is one modular application until a real strain shows you where to cut. Leaders Loop

The cheaper path: build Greenrows as one application with clean internal modules, catalogue, cart, checkout, separated in the code but deployed together, sharing one database. They launch faster, change checkout with a single edit, and test the whole journey in one place. Six months and a hiring round later, checkout is the part that buckles under Black Friday traffic and the new payments squad keeps getting blocked behind the catalogue team's releases. Now the split makes sense: they extract checkout into its own service, owned by the payments squad, along a seam the monolith already showed them. The architecture grew into the organisation, not ahead of it, and every part they did not split stayed simple.

Frequently asked questions

Aren't microservices just the modern, correct way to build?

No, they are a trade-off, not an upgrade. They buy independent deployment and scaling for separate teams, and they charge for it in operational complexity: network failures, distributed data, more pipelines, harder debugging. For a single team or an early product, that bill usually outweighs the benefit. The architecture should match your problem, not the logos of companies far larger than you.

If a monolith is fine, why did the big companies move to microservices?

Because they hit the problem microservices solve: hundreds or thousands of engineers in many teams, all trying to ship through one deployment, blocking each other constantly. At that scale, independent services let teams move without colliding, and the operational cost is worth it. The mistake is assuming you need their solution before you have their problem.

What is a "distributed monolith," and why is it the worst outcome?

It is a system split into separate services that are still so tightly coupled they must be deployed together. You pay the full cost of distribution, network calls, scattered data, multiple pipelines, while getting none of the independence that was the whole point. It is usually the result of splitting a system before you understood where the real boundaries were.

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

Yes, and that is the recommended path. Build a well-modularised monolith with clean internal boundaries, then extract services one at a time when a genuine strain appears, a part that needs independent scaling, or a team that keeps getting blocked. Good internal modularity is what makes that later extraction straightforward rather than a rewrite.

How do I know when it's actually time to split?

Watch for organisational and operational pain, not aesthetics. Teams routinely blocked waiting for each other's releases; one component that needs to scale very differently from the rest; a deployment that has become so risky everyone fears it. When a specific, recurring pain points at a specific seam, extract that seam, and leave the rest alone.

Related in the Toolkit

This decision sits on top of how requests actually travel between machines (how the web works) and how the back end is organised (server-side databases, APIs and services), and because microservices are run, not just written, the way you host them (hosting & cloud architecture) often costs more than the code.

Where to go next