Back to blog

Monolith vs. Microservices: Choosing the Right Architecture for Your Team Size

Software ArchitectureMicroservicesBackend DevelopmentEngineering Leadership

The monolith versus microservices debate is one of the most consequential architecture decisions a team makes, yet it is often driven by trends rather than context. Microservices are not progress in themselves; they are an answer to specific problems that many teams do not yet have.

When a Monolith Is the Better Choice

For most teams in early stages, a well-structured monolith is the superior option. Teams of fewer than ten engineers do not benefit from the distributed complexity that microservices introduce. Network latency, distributed transactions, and service discovery are problems that overwhelm a small team. Products still searching for product-market fit need maximum iteration speed. A monolith allows domain boundaries to be shifted without coordinating deployments across multiple services. Domains that are not yet fully understood should not be carved into services. An early wrong cut creates more coupling than a thoughtful monolith.

# Warning sign: microservice overhead for a small team
# Starting a local development environment with 12 services
docker-compose up --scale user-service=1 \
                  --scale order-service=1 \
                  --scale payment-service=1 \
                  --scale notification-service=1
# Onboarding time: 2-3 days for the local environment alone.
# For a team of 4 developers, this is not progress.

When Microservices Pay Off

Microservices have genuine value, but only under specific conditions. Teams large enough to own individual services need clear ownership boundaries. The rule of thumb: one service per team, not multiple teams per service. Established domain boundaries are a prerequisite. Microservices should reflect boundaries that already exist in the business, not those that are hoped for. Different scaling requirements per service can justify microservices: a compute-intensive service needs different resources than a lightweight API gateway. Organisational structures that enable independent deployments are essential. Conway's Law applies in both directions.

Why This Matters

The wrong architecture for a team's size creates overhead that never pays off. Conway's Law describes precisely what happens in practice: the architecture of a system mirrors the communication structure of the organisation. Cutting services according to wishful thinking rather than actual team boundaries creates coordination costs with no return. An Architecture & AI Review evaluates the current stack in the context of team size and delivers a clear recommendation for which architectural direction will hold over the next 18 months.