How to Choose

Microservices or modular monolith: the right decision for a product start

Architectural choice between microservices and modular monolith for a new product or growing company is one of the most frequent where wrong decisions are made under marketing influence. Selection criteria, typical mistakes, and approaches by team size and maturity.

Discuss Your Challenge

Comparison article: microservices versus modular monolith for product start. Selection criteria by team size, DevOps maturity, domain stability.

What is being compared

Two architectural approaches for a new product or growing product team. Microservices — breaking the system into independently deployable services, usually by business domain. Modular monolith — single system with explicit modules and inter-module interfaces, deployed as one artifact. Hybrid — modular monolith with extraction capability for parts as growth happens — also considered.

When option is justified:Microservices

Microservices are justified when the development team is 50+ engineers with mature DevOps (CI/CD, observability, on-call), the business domain divides clearly into independent sub-domains with different load and change rates, scaling requirements differ substantially across system parts. The path of large enterprise teams and products with real load. For small teams, microservices are a burden.

When option is justified:Modular monolith

Modular monolith is justified for most regional product teams. Team of 5-30 developers, moderate scaling requirements, business domains still forming and may change, DevOps operational maturity in formation. Modular monolith provides start speed, deployment simplicity, unified state tracking. With proper module boundaries — provides ability to later extract parts into microservices without revolution.

When option is justified:Hybrid: modular monolith with extraction capability

Hybrid is justified for a growing team planning scaling 2-3 years ahead. Starts as modular monolith with explicit module boundaries and inter-module contracts. As growth happens and real causes appear (load, different teams on different modules), individual modules are extracted to microservices. The path of mature product teams avoiding premature optimization.

Common mistakes when choosing

Starting with microservices in a 5-10 developer team — operational load exceeds benefits, progress slow
'Microservices by tables' — each table in a separate service without business logic, results in distributed monolith with network calls
Ignoring DevOps maturity — without observability, distributed tracing, on-call, microservices architecture is unmanageable
Modular monolith without clear boundaries — turns into spaghetti monolith later impossible to split
Premature extraction to microservices by fashion, without real cause — operational expenses grow without business effect
Hybrid path without explicit decision — end up with part monolith, part microservices, no one understands what is where

Criteria for decision-making

Development team size — under 20: modular monolith, 20-50: modular monolith with extraction prep, 50+: microservices justified
DevOps maturity — presence of CI/CD, observability, on-call. Without mature DevOps, microservices create more problems than they solve
Business domain stability — if domain boundaries are clear and stable, microservices by domain make sense. If domains still forming — modular monolith provides flexibility
Scaling requirements — real, not theoretical. If different system parts have substantially different load, microservices justified
Regulatory requirements — for banks and fintech, specific isolation requirements may exist (e.g., AML), which can justify microservices
Long-term team strategy — growth to 100+ engineers in 3-5 years gives basis for preparing for microservices from the start

→

What else is worth exploring

Topics from the same area we usually explore together

Solution

These are not just articles

I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.

Discuss applying this →

← Back

Ready to discuss your challenge?

Tell me what's not working or what needs to be built. First conversation — no obligations.

Discuss Your Challenge Write on Telegram

Usually respond within a few hours