Modular Monolith or Microservices: A Decision Guide

The appeal of microservices is usually independent deployability and clear ownership boundaries, not literally running separate processes. A modular monolith, one codebase with enforced internal boundaries between modules, each with its own owner and a narrow interface, gets you most of that clarity without the operational tax of running, monitoring, and securing a dozen separate services. If your actual complaint is that the codebase feels tangled and nobody's sure what's safe to change, enforcing module boundaries inside a single deployable often fixes the real problem faster than a service split does.

The strongest reason to extract a genuine microservice is that one part of your system needs to scale, deploy, or fail independently of the rest: a video processing pipeline with wildly different resource needs than your main API, or a component owned by a team that ships on a different cadence and keeps getting blocked by unrelated changes elsewhere in the codebase. Splitting along organizational convenience alone, without one of those forcing functions, tends to produce services that still deploy together in practice because they're too tightly coupled to release independently.

Each service you extract needs its own authentication to its neighbors, its own certificate or token lifecycle, and its own place in your network policy, none of which existed when the same code lived inside one process calling a function directly. Teams that split services without budgeting for this tend to end up with either an unauthenticated internal network they quietly trust by default, which undermines a zero-trust posture, or a proliferation of ad hoc auth schemes between services that nobody fully documented. Count this cost explicitly before splitting, not after the first internal security review flags it.

Independent, frequent releases are the entire point of decoupling services, so track deploy frequency per component after a split, not just once. DORA's research groups engineering teams by deployment frequency, and the spread between clusters is wide: the strongest teams release on demand while the weakest can go as long as 180 days between releases¹. If your services are technically separate but still get released together in lockstep because of shared dependencies or a shared release process, you've paid the operational cost of microservices without collecting the benefit, and that gap between measured deploy frequency and the promise of independence is worth reviewing a few months after any split.

A distributed monolith happens when services are split at the process level but still share a database, deploy in lockstep, or call each other synchronously in long chains that break together. It combines the network latency, partial failure modes, and operational overhead of microservices with the tight coupling of a monolith, without the benefit of either. If a single change routinely requires coordinated deploys across three or four services, that's usually the sign the boundary was drawn in the wrong place, not that you need a fifth service.

Few real systems are cleanly one architecture end to end. It's common and reasonable to run a modular monolith for the bulk of your product logic while extracting one or two genuine microservices for the pieces that have a real independent scaling or ownership need. Make the call boundary by boundary against the criteria above, rather than picking an architecture as a company wide identity and forcing every new feature to fit it.

Questions to answer for each candidate boundary:

• Does this component need to scale, deploy or fail independently, or have very different resource needs from the main API?
• Is a team that ships on a different cadence repeatedly blocked by unrelated changes elsewhere in the codebase?
• Have you budgeted authentication, certificate or token lifecycle, and network policy for the new service boundary?
• Will the new service avoid sharing a database or deploying in lockstep, which would create a distributed monolith?
• Will you track deploy frequency for this component after the split to confirm the change helped?