Monoliths and microservices are not old versus modern. They are different trade-offs.

A monolith is simpler to build, deploy, debug, and keep consistent. Microservices help larger teams move independently, isolate failures, and evolve parts of the system separately.

The right choice depends on team size, ownership boundaries, operational maturity, and how often teams block each other.

This chapter covers where each architecture wins, where the costs come from, and why starting with a monolith is often the safer default.

Start with the scorecard. The rest of the chapter explains each row.

Look at the left column for a moment. Every item there is something you get for free on day one, with no extra tooling. Now look at the right column. Every item there is something you need only once you have grown past a certain size.

That difference in timing is why the order of operations usually runs monolith first, microservices later, and almost never the reverse.

The cost of microservices is not in writing the services. Writing a small service is easy. The cost is in everything you now have to run around them.

With one monolith, a request enters one process, runs, and returns. You have one thing to deploy, one set of logs to read, one place to attach a debugger. When something breaks at 3am, the on-call engineer looks in one place.

Split that into fifteen services and the picture changes. A single user request now crosses process boundaries, so you need distributed tracing to follow it. Fifteen services means fifteen deploy pipelines, fifteen sets of dashboards, fifteen on-call surfaces, and a service-to-service network that can fail in ways an in-process call never could.

You need service discovery so the services can find each other, centralized logging so you can search across them, and a way to roll out a change to one without breaking its callers.

This is why a small team running thirty services is usually worse off than the same team running one. The work of operating the fleet outweighs the work of building features.

A six-person team can spend most of a quarter keeping a service mesh and twelve deployment pipelines healthy, shipping almost no product in the meantime. The architecture is technically "microservices." It is also stalling the roadmap.

The rule of thumb is simple: do not adopt an operational burden you cannot staff. If no one can own tracing, deployment automation, and the failure modes of a distributed system, every service you add is a liability.

In a monolith, one module calling another is a function call. It costs nanoseconds and it never fails on its own. The moment that call crosses the network to another service, it costs milliseconds and it can time out, get lost, or hit a service that is down.

That cost compounds when calls chain. Consider a request that has to touch five services in sequence, each one calling the next.

In the top path, the module-to-module calls are effectively free. The only real latency is the database round trip at the end.

In the bottom path, every arrow is a network hop with its own round-trip time. At a modest 10 milliseconds per hop, a four-hop serial chain adds 40 milliseconds before any service has done a microsecond of real work. Add retries and the tail latency gets worse.

The fix is not "avoid microservices." It is to design so that the common request path does not fan out into a deep serial chain. That means keeping related logic inside one service, calling downstream services in parallel where you can, and pushing slow side-effects onto asynchronous events instead of blocking the user on them.

The network is not free, and a design that looks clean on a whiteboard can be slow in production purely from hop count.

This trade-off is easy to overlook, because it stays invisible until a cross-service operation fails partway through.

In a monolith with one database, updating several tables atomically is trivial. You wrap them in a transaction. Either all the writes commit or none of them do, and the database guarantees it.

Debit one account, credit another, and if anything fails in between, the whole thing rolls back. You get this correctness for nothing.

Split those tables across services and that guarantee disappears. There is no transaction that spans the Payment service's database and the Order service's database. If the payment succeeds and the order write fails, you now have money taken and no order to show for it. You have to handle that yourself.

Every cell in the right column is real engineering work that the left column gave you for free. Sagas, the outbox pattern, idempotent consumers, and eventual consistency are the tools that replace the transaction you used to take for granted. They work, but they are not free and they are not simple.

When someone proposes splitting a tightly transactional core (say, the ledger of a payments system) into separate services, the consistency cost is the first thing to put on the table.

The driver behind most microservices adoptions is people rather than performance.

A monolith works well when a handful of teams share it. It starts to hurt when too many teams try to change the same codebase at once. Merges get painful.

The build slows down. Every team's release is held hostage by every other team's half-finished work, because they all ship together. At that point the bottleneck is not the machine, it is coordination between humans.

This is Conway's Law showing up in practice: the shape of your software ends up mirroring the shape of your organization. When you have forty teams and one deployable, those forty teams are forced into lockstep no matter how clean the code is.

Microservices start to pay off precisely when the number of teams outgrows what a single codebase can absorb without constant coordination. Give each team its own service and its own deploy pipeline, and they stop waiting on each other.

This matters for design because team count is a reliable signal for whether microservices are warranted. A 5-engineer startup splitting into services is solving a coordination problem it does not have yet. A 300-engineer company on one monolith is drowning in a coordination problem it cannot merge its way out of.

Tying the service boundaries to team boundaries is what separates a thought-through design from copying a pattern without the context that justifies it.

The velocity argument is where both camps cherry-pick. Microservices advocates point at large companies shipping fast. Monolith advocates point at startups shipping faster. Both are right, because they are talking about different points on the timeline.

Early on, a monolith is faster. There is one place to add a feature, no network code, no contracts to negotiate, no eventual consistency to design around. A small team can move very quickly. Microservices at that stage add ceremony that buys nothing, because the coordination problem they solve does not exist yet.

Later, once enough teams are fighting over one codebase, the lines cross. The monolith's single deploy and shared code turn into a tax on every team, and the per-service autonomy of microservices starts to win back more time than its overhead costs.

The mistake is treating this crossover as a fixed date rather than a condition. You do not split because you hit a headcount number. You split when coordination has measurably become the thing slowing you down.

The debate is usually framed as two choices, which is a big part of why teams get it wrong. There is a third option that fits more situations than either extreme: the modular monolith.

A modular monolith is one deployable artifact with clean, enforced module boundaries inside it. Each module owns its domain, exposes a clear internal interface, and does not reach into another module's internals or tables.

It ships as a single unit, so you keep the simplicity, the in-process speed, and the ACID transactions. But the boundaries are real, which means that when you do need to extract a module into its own service later, the seam is already there.

The modular monolith sits in the middle of the spectrum, and that middle is where most pre-Series-B startups belong. You get most of the architectural discipline of microservices, with clear ownership and decoupled domains, without paying the operational and consistency costs until you need to.

When the day comes that one module needs to scale separately or one team needs to deploy independently, you extract that single module into a service. The boundary work is already done.

For a small team, a modular monolith is often the soundest recommendation, because it captures the costs of distribution and avoids paying them prematurely.

The last piece is the strongest argument for caution: splitting and merging are not equally hard.

Going from a monolith to services later is expensive, but it is a well-understood, incremental process. You extract one boundary at a time, usually behind a facade, and you can stop or slow down whenever you like. Teams do this successfully all the time.

Going the other way, collapsing a sprawl of premature services back into something coherent, is far harder. You have data spread across many stores with no transactions tying them together, network contracts baked into every interaction, and operational tooling built around the fragmentation.

Undoing that often means a rewrite. Premature decomposition is one of the few architectural mistakes that can be close to irreversible.

That asymmetry is the whole argument for restraint. If you start with a monolith and turn out to need services, you pay a known, incremental cost to split. If you start with services and turn out not to need them, you pay a much larger cost, and sometimes you cannot pay it at all.

When the future is uncertain, and it always is, you want the option that is cheap to get wrong.

Pulling it together, the decision comes down to a handful of honest questions, roughly in order of how much they should weigh on the answer.

When most of these point at a small team, low coordination pain, and tight consistency, the answer is a monolith or a modular monolith. When they point at many teams, frequent deploy contention, and a mature platform, microservices are worth their cost.

The skill is reading which situation you are in, rather than naming a single "best" architecture.

That reading is what the next chapter sharpens: the concrete signals that tell you when to adopt microservices, and the counter-signals that tell you to wait.