Monolith vs microservices: where does the complexity live?

A monolith is a single deployable codebase and process for the whole application. Microservices split that application into independently deployable services that talk over the network. The code inside a monolith still has module boundaries — the difference is whether those boundaries are enforced by a network call (microservices) or by convention within one process (monolith).

Most successful microservice architectures started as a monolith and split along real, observed seams once team size or scaling pressure demanded it. Splitting along GUESSED boundaries before you understand the domain tends to produce a "distributed monolith" — every service still tightly coupled and chatty, so you pay the full network/ops overhead of microservices while getting none of the independent-deployability benefit that was the entire point.

It's tempting to think the decision to split is about codebase SIZE — once it gets big enough, split it. But Conway's Law (system architecture tends to mirror the communication structure of the organization that builds it) points at the actual mechanism: a monolith maintained by 3 engineers rarely needs splitting no matter how much code it has, because there's no coordination bottleneck between people to route around. A monolith blocking 15 independent teams from deploying without stepping on each other's changes has a real problem — but it's an ORGANIZATIONAL one (too many people needing to move independently through one release process), and microservices solve it by giving each team its own deployable unit, not by making the code itself better.

This is why splitting "for clean architecture" without that organizational pressure usually backfires: you've paid for network calls, service discovery, distributed tracing, and eventual consistency — real, ongoing costs — to solve a coordination problem that didn't actually exist yet. The split becomes worth its cost exactly when the number of people who need to deploy independently, without waiting on each other, exceeds what one release process can comfortably serialize.

At 5 engineers, the startup ships a single Rails or Django monolith, one deploy for everything — the right call, because there's no team-coordination pain to solve yet, and splitting now would add distributed-systems overhead for zero organizational benefit. Every engineer can still hold the whole system in their head, and one deploy pipeline serves everyone fine.

Three years later, at 80 engineers, deploys start queuing behind each other because every team shares the same release train — and worse, the checkout team's flaky test occasionally blocks the catalog team's unrelated deploy from going out. THAT specific, observed pain — teams genuinely blocked on each other, not a code-quality complaint — is the real signal to split checkout, catalog, and search into independently deployable services. Notice the trigger wasn't a predetermined size or a calendar date; it was the organizational bottleneck actually showing up.