Every six months a different team asks us the same question: “Should we be on microservices?” The honest answer for most teams under 30 engineers is no — and the honest reason isn’t “monoliths are cool again,” it’s that microservices solve organizational problems, not technical ones.
If you don’t have the organization that microservices were designed for, you get the operational cost of microservices without the benefits. Here’s the framing we use.
What microservices actually buy you
Microservices give you independent deployability per team. That is the single benefit; everything else (scalability, fault isolation, technology diversity) is either a side-effect or a marketing claim.
Independent deployability matters when you have enough teams that they’d step on each other’s release schedules in a shared codebase. Rule of thumb: at 30+ engineers across 5+ product areas, microservices start paying off. Below that, the coordination overhead they impose is bigger than the coordination overhead they save.
The modular monolith: a better default for small teams
A modular monolith is a single deployable, but internally organized into modules with clear boundaries — ideally each module exposes a public interface, owns its database tables, and forbids cross-module access except through that interface.
You get:
- One repo, one CI pipeline, one deploy — zero distributed-systems debugging
- Transactions across modules when you need them (you will)
- Refactoring across modules in a single PR (you will)
- The option to peel off a module into its own service later, when the team grows
You miss:
- Per-team deploy independence (only relevant once you HAVE multiple teams)
- Per-service horizontal scaling (almost no one actually needs this until later)
The microservices tax most teams underestimate
Distributed systems have a tax that compounds:
- Network calls fail.Every cross-service call needs retries, timeouts, circuit breakers, idempotency keys. Code you didn’t have to write before.
- Eventual consistency.Two services + one event bus = a saga pattern, compensating transactions, and weekend incidents about “why is the order in service A but not service B?”
- Observability.Distributed tracing, structured logging across services, correlation IDs — mandatory infrastructure that doesn’t exist in a monolith because the call stack already does that job.
- Local dev.“Run the app” goes from one command to docker-compose with 12 containers. Onboarding gets slower; CI gets longer.
None of these are dealbreakers IF you have the team to absorb the cost. They are dealbreakers if you don’t.
When microservices are actually right
- You have 30+ engineers organized into 5+ teams who can’t plausibly all merge to one main branch comfortably.
- You have a workload with genuinely different scaling profiles — e.g. one surface needs 200 cores for 30 minutes a day, the rest needs 4 cores all day.
- You have a regulatory boundary — one piece must live in a hard-isolated environment (PCI scope, healthcare PHI, etc.).
- You have a tech-stack boundary that can’t be bridged — ML inference must be in Python, the rest of the system is in Go.
If none of these apply, you have a team-cost problem, not a service-architecture problem.
The middle path that actually works
Start as a modular monolith. As the team grows past ~20 engineers, identify the ONE module that’s cleanly separable AND whose team is feeling the deploy-coordination pain. Peel it off as a service. Repeat as needed. You’ll end up with a “monolith plus a few services” architecture — which is what most successful companies actually run, even the ones that talk about “microservices at scale”.
How we approach this
Default for the SaaS products we build through SaaS Product Development is a modular monolith with strict module boundaries — ready to be peeled apart when the team is big enough to need it. We’d rather extract a service in week 80 than write distributed-systems plumbing in week 8.
Takeaways
- Microservices solve team-coordination problems, not technical problems.
- Below ~30 engineers, modular monolith wins on every axis.
- The microservices tax (network, consistency, observability, dev-loop) is real.
- Extract services as the team grows, one at a time, only when the pain shows up.
- Most “microservices” companies actually run monolith-plus-a-few.
