Monolith or services: how to make the call without an engineering background

If you own or run a company with a working product, sooner or later your CTO or a contractor walks in with a proposal: "We need to move to microservices." It sounds inevitable. Sometimes it is. More often it is not.

I have seen enough of these transitions to say this: the decision is not primarily a technical one. It is an organisational and operational one. And that is exactly why it is worth understanding at the business level, not just at the code level.

What a monolith actually is

A monolith is when the entire application is deployed as a single unit. A change in any part requires rebuilding and restarting everything. Teams work in one shared codebase.

There are real advantages to that. It is simpler to maintain a single data schema. Simpler to debug - everything is in one place. Less infrastructure complexity. For most products at an early or mid stage, a monolith is the right choice.

Problems start when the team grows large enough that people are constantly stepping on each other in the same codebase. Or when different parts of the product need to scale in fundamentally different ways. Or when every small change requires a full release cycle.

What microservices actually are

Microservices means splitting the application into independent components, each deployed and scaled separately. Different teams can work and release independently.

That sounds appealing. But you pay for it: network calls between services that can fail. Separate databases that need to stay in sync. Orchestration infrastructure to run. Each service needs independent monitoring. The simple task of "figure out what went wrong" becomes a detective story across multiple logs.

Microservices solve problems of team scale and load scale. If you have neither problem, the transition will add complexity without adding value.

The right question to ask your team

When the CTO proposes a transition, the right question is not "is this modern?" and not "is this what everyone does?". The right question is a set of concrete things:

1. What specific problem are we solving right now - slow releases, team conflicts, load problems?
2. How many people are working in the codebase at the same time?
3. Does the team have experience managing distributed systems?
4. What is the effort estimate for the transition, and who will own it?
5. What happens to current product work during the transition?

If there is no concrete answer to the first question, the conversation is premature.

Signs the transition is justified

A few signals after which the conversation becomes concrete:

• The engineering team has grown to 15-20 people in one codebase and the release cycle is broken by constant conflicts.
• Different parts of the system have fundamentally different scaling requirements.
• A specific module has become a bottleneck that cannot be scaled independently from the rest.
• Regulatory or security requirements demand strict isolation of certain components.

Signs the transition is premature

The other side of the picture:

• The team has fewer than 10 engineers.
• The product is still actively searching for its shape - functionality is changing fast.
• There is no dedicated infrastructure engineer or SRE who will manage all of this.
• The transition is proposed because "that is how it is done" or "we want to try it", not because of a specific pain.

A monolith written with discipline runs for years and serves millions of users. Microservices introduced without a mature infrastructure team turn into a distributed monolith with extra pain.

An architecture decision is first of all a decision about how the team is organised. That is where the conversation should start.