Microservices vs Modular Monolith: A Decision Framework for Teams Under 20

A team of twelve engineers ships a new feature every three weeks. Their build pipeline runs seventeen services, deployment requires coordinating four repositories, and last Tuesday a broken user-preferences endpoint took the checkout flow offline for ninety minutes. Nothing about their architecture is wrong on paper. It is simply wrong for them. Choosing between microservices and a modular monolith is rarely a purely technical question. It is a question of whether the operational cost of your architecture matches the size and speed of the team that has to operate it.

The hidden cost is not the code, it is the operations

For a team under twenty engineers, the code you write to expose a capability over HTTP is trivial compared to everything you have to build around it. Each service needs its own deployment pipeline, its own monitoring, its own alerting rules, its own on-call playbook, its own database migration story, and its own contract tests with the services that call it. That plumbing costs roughly the same whether the service does one thing or a hundred. When a small team runs a dozen services, they pay that fixed cost twelve times over, using the same engineers who are supposed to be building product.

A modular monolith flips the ratio. One deployment pipeline. One log stream. One database with a shared migration timeline. Modules communicate through typed function calls that fail at compile time instead of JSON contracts that fail in production at 3 AM. The discipline of keeping module boundaries clean is still real work, but the operational overhead is close to zero. The result is that a team of ten can operate a well-structured monolith with almost no dedicated platform investment, while the same team running microservices typically ends up with one or two engineers permanently absorbed by infrastructure work.

Head-to-head: five decisions where the two diverge sharply

Deployment cadence

Microservices allow independent deploys in theory. In practice, small teams rarely have truly independent services. A change to the pricing service usually needs a coordinated release with the order service and the invoicing service. You inherit the coordination cost of a monolith while losing the atomic-deploy safety of one. A modular monolith deploys once. The whole thing either works or rolls back together. For a team shipping weekly rather than hourly, this wins on both speed and predictability.

Debugging

When a request in a microservices system fails, you follow it across three or four hops of network, deserialization, retries, and timeouts. Distributed tracing helps but does not replace a stack trace. In a modular monolith, a single stack trace shows the entire call path on one screen. For a small team, engineer-hours spent debugging are the scarcest resource in the company. Anything that reduces them translates directly into feature velocity, which translates directly into revenue.

Scaling

The classic argument for microservices is that you can scale hot components independently. This is genuinely true, but rarely relevant at the scale a twenty-person team operates. Most systems bottleneck on the database long before they bottleneck on any single service's CPU. A well-designed monolith with a read replica, a caching layer, and a background job queue handles more traffic than people expect. If you do outgrow it, the modular boundaries make extraction of one hot module into its own service a straightforward refactor, not a rewrite from scratch.

Hiring and onboarding

A new engineer on a microservices team spends the first two weeks learning the deployment tooling, the service catalog, the shared libraries, and the twelve places where state lives. On a modular monolith, they clone one repository, run one command, and can trace any behavior end-to-end in their IDE on day two. In a hiring market where senior engineers are expensive and time-to-productivity is measured in weeks, the monolith reduces onboarding cost substantially. That is money you did not spend, on capacity you gained sooner.

Failure isolation

This is the one place microservices genuinely win. A bug in one service does not directly crash the others. But for a small team, "does not crash" often means "silently returns stale or wrong data", which is arguably worse than an explicit outage because it takes longer to detect. Circuit breakers, timeouts, retries with backoff, and graceful degradation are non-trivial to implement well, and small teams almost always underinvest in them. A monolith fails loudly and completely, which is easier to alert on and easier to recover from.

When microservices actually pay off

There are three patterns where microservices earn their operational tax honestly. First, when different parts of the system have genuinely different runtime characteristics: a real-time video processing pipeline sitting next to a CRUD admin panel that serves ten internal users. Second, when independent teams need to ship on independent cadences without coordination overhead, which typically means you have crossed the 30 to 40 engineer threshold and organizational boundaries have hardened. Third, when a single component has hard scaling requirements, such as an event ingestion endpoint receiving millions of requests per hour, that would distort the resource shape of everything else if colocated.

If none of those three conditions applies to your business, microservices are almost certainly costing you more than they save. And it is worth being honest with yourself about whether they truly apply today, or whether they might apply in some hypothetical future that may never arrive.

The modular monolith as a bridge

The most defensible architecture for a team under twenty is a modular monolith with clean, enforced boundaries between modules. Each module owns its own data. It exposes a narrow, typed interface to other modules. It has no direct cross-module database reads, no circular dependencies, and no shared mutable state leaking across boundaries. Enforce this with directory structure, package rules, linting, and code review. Treat every violation as a real bug.

Done well, this gives you the operational simplicity you need today and the architectural optionality you might need in two years. When the day comes that one module genuinely needs to scale independently or ship on its own cadence, extracting it becomes a mechanical refactor rather than a multi-quarter archaeology project. You get the benefits of microservices only when you actually need them, and you pay for them only then.

The right architecture is the one your team can operate well at your current scale, with a clear evolution path for the scale you might reach. For most SME-sized teams, that is a modular monolith, not a distributed system. If you are weighing a redesign, or you have inherited a microservices sprawl that is slowing your team down, an experienced partner can help you map the real cost surface and design a migration that does not stall your roadmap. The MerkTechs team has walked this path with clients across e-commerce, fintech, and internal-tools work, and we are happy to talk through the tradeoffs for your specific situation.