Modular Monolith or Microservices: A Framework for Deciding Without Dogma

Picture a team starting a new product. Before the first user signs up, the architecture diagram already has ten services, a message broker and an orchestrator. It looks modern. It looks scalable.

Three months later, a simple change, say adding a field to an invoice, touches four services, needs four coordinated deployments, and fails in a way nobody can trace. Every call that used to be a function call is now a network request, and the team spends more time keeping the pieces talking than building the product.

The distributed monolith

This is the distributed monolith: everything is still coupled, but now over the network. It's what happens when the architecture is chosen by fashion instead of by need.

Start simple, extract on demand

After more than 20 years designing systems, my position is this: start with a modular monolith and extract services only when a concrete reason demands it. This article isn't a defense of the monolith. It's a framework for deciding based on criteria you can verify.

The useful question was never "microservices or monolith?" but: what concrete problem am I solving, and how much does it cost to solve it this way?