Microservices solve an organizational problem, not a technical one: too many engineers stepping on each other in one codebase. If you’re a small team, you don’t have that problem yet, and adopting the solution anyway just hands you a distributed systems problem you didn’t need.

What actually happens when a five-person team splits into services

You don’t get independent deployability, you get a distributed monolith — every service still has to deploy in the right order relative to the others, because they were never really decoupled, just split across a network boundary. Except now:

• A single feature touches three repos instead of one file.
• Local development means running four services and their four databases just to test one change.
• A bug that used to be a stack trace is now a hunt across service logs with no shared request context, unless you’ve also built distributed tracing — which is its own project.
• Every API change between two services needs coordination that, in a monolith, would’ve been a single PR.

None of this is hypothetical inefficiency. It’s the actual daily cost, paid by a team too small to have the problem microservices were built to solve.

The costs that hit a small team first

Network calls where function calls used to be. A function call fails in exactly one way: it throws. A network call fails in a dozen ways — timeout, partial response, the other service mid-deploy, a transient DNS hiccup — and your code now has to handle all of them, for every single interaction that used to be free.

Data consistency stops being free. In a monolith, a database transaction makes multi-table updates atomic for nothing. Split across services, you need sagas, compensating transactions, or eventual consistency — real complexity that a small team now has to design and maintain, for a guarantee they used to get from BEGIN; COMMIT;.

Operational surface area multiplies. Each service needs its own deploy pipeline, its own monitoring, its own on-call runbook. A five-person team maintaining twelve services is a five-person team that no longer has time to build the product.

The modular monolith alternative

Get the organizational benefit — clear boundaries, independent development within them — without the network. Structure the codebase into modules with enforced boundaries (no importing another module’s internals, only its public interface), deployed as one process:

src/
  billing/       # only exposes billing/index.ts
  users/         # only exposes users/index.ts
  notifications/

This gives you most of what people actually want from microservices — the ability to reason about one module without reading the whole codebase, and a clear seam if you ever do need to split it out — without paying the network, deployment, and consistency tax on day one.

When microservices actually earn their cost

• Multiple teams (not multiple engineers — multiple teams) need to deploy independently without blocking each other.
• One part of the system has wildly different scaling needs than the rest — a video transcoding pipeline next to a CRUD API, say — and running them together wastes resources or complicates capacity planning.
• You have the operational maturity already in place: CI/CD per service, distributed tracing, service-level monitoring. If you’d need to build all of that from scratch to make the split viable, you’re not ready for the split yet.

The honest question to ask

Not “could this be microservices,” almost anything could. Ask: which specific team-coordination problem, that we actually have today, does this solve? If the honest answer is “none yet, but we might grow into needing it,” you’ve just described premature optimization with extra YAML. Build the modular monolith. Split it when the pain of not splitting is real, not anticipated.