Microservices vs monolith is one of those debates where everyone has a strong opinion shaped by their last bad experience. The team that got burned managing a 300k-line Rails codebase with 40 engineers swears by microservices. The team that spent six months debugging a distributed tracing mess swears by the monolith. Both are right. Neither answer generalizes.
Here’s how we actually think through this when a client asks.
Quick take
Start with a monolith. Move to microservices when the monolith starts hurting in specific, measurable ways: teams blocking each other on deploys, one component melting under load while the rest idles, or a piece of the system that genuinely needs a different runtime. Those are real signals. "We might need to scale someday" is not.
The case for monolith
It's just simpler to ship
One repo, one build, one deploy. A new engineer can clone the project, run it locally, and open a PR on day one. No service mesh, no inter-service contracts, no figuring out which of eight services owns the bug you’re looking at. The baseline is simple, and you earn complexity only when the problem demands it.
Shared code is actually shared
In a monolith, shared logic (validation, domain models, formatters) is an import statement. In microservices you’re either duplicating it across services, publishing internal packages with their own versioning hell, or making network calls to a "shared service" that becomes a single point of failure. None of those are free.
Debugging is not a production investigation
When something breaks in a monolith, you have one stack trace and one log stream. In a microservices system, a single request touching five services means five log streams, a distributed trace to correlate, and a reproduction that requires spinning up multiple services locally. Distributed tracing is a solved problem technically, but it only works if you’ve invested in the tooling. Most teams haven’t.
Where monolith breaks down
Scaling the whole thing when you only need part of it
A monolith scales as one unit. If your video transcoding pipeline spikes while your API gateway is idle, you still pay to scale both. At low traffic this doesn’t matter. At serious scale, it gets expensive fast.
Big teams stepping on each other
One codebase with five engineers is fine. With 50, you get merge conflicts every day, deployment coordination meetings, and nobody being sure who owns what. The monolith doesn’t cause this problem, but it amplifies it. The organizational overhead starts eating real engineering time.
Tech stack lock-in
If your monolith is Go, everything is Go. Even the parts where Python would cut development time in half. Adopting a new language or database means either migrating the entire system or bolting something on awkwardly. The coupling that makes monoliths easy to start with is the same thing that makes them painful to evolve.
The case for microservices
Scale exactly what needs scaling
Each service scales on its own. Your recommendation engine can run on GPU instances while the auth service runs on the smallest box available. You pay for what actually needs the resources, not a flat tax on the whole system. For uneven workloads, this matters a lot.
Teams that actually own their stuff
When a team owns a service, they own the deploy, the tech stack decisions, and the on-call rotation. They ship without asking anyone else. For large engineering orgs, this is usually the real reason to go with microservices. Not the technical properties. The organizational ones.
Failures stay contained
If your payment service goes down, users can still browse and add to cart. With proper circuit breakers, a failure in one service doesn’t cascade through the system. That kind of fault isolation is structurally impossible in a monolith where one bad actor can crash the whole process.
Ships don’t block each other
A monolith that deploys once a day becomes a coordination problem when 10 teams all want to push. Microservices let each team deploy on their own schedule, dozens of times a day if needed. The release train stops being a bottleneck.
The real cost of microservices
Distributed systems are genuinely hard
Network partitions happen. Services go down mid-request. Messages get duplicated. What used to be a function call is now an HTTP request that can fail in 10 new ways. You need service discovery, circuit breakers, retries with backoff, and distributed tracing just to match what a monolith gave you out of the box. Teams that skip this part ship systems that are slower and buggier than the monolith they replaced.
More services, more everything
Each service needs its own pipeline, its own monitoring, its own alerts, its own runbook. The tooling to run microservices well (service meshes, container orchestration, secrets management, distributed tracing) is real infrastructure with real cost. At small scale, this overhead isn’t buying you anything.
Security surface grows fast
In a monolith, internal calls are in-process and trusted by default. In microservices, every hop crosses a network boundary and needs auth, encryption, and auditing. The attack surface expands and managing it requires processes that simply don’t exist yet in most small teams.
Testing across services is painful
Integration tests need multiple services running. End-to-end environments are expensive to maintain. Contract testing, service virtualization, chaos engineering, these are entire disciplines you’re signing up for. Monolith teams don’t deal with any of it.
What actually drives the call
Team size
Under 15 engineers, the coordination overhead of microservices kills you before the benefits show up. Above 50 engineers on the same system, a monolith starts creating organizational drag that microservices fix. Somewhere in between, it depends on how your teams are structured.
How stable are your domain boundaries
If your product is still changing shape, you don’t know where the right service splits are yet. Microservices freeze those lines in place through network contracts. Drawing them wrong early is how you end up with services that are the wrong size and can’t be reorganized without a rewrite.
Is the load actually uneven
If every part of your system scales together, microservices don’t help much. If some components get 1000x the traffic of others, targeted scaling makes real economic sense. Most early-stage products don’t have this problem yet. They just worry they might.
Do you have platform engineering
Microservices without solid CI/CD, monitoring, and incident response culture are a liability. The tooling has to come before the services, not after. Most teams that struggle with microservices tried to do it in the wrong order.
What we do in practice
We start almost every greenfield project as a well-structured monolith. Not a spaghetti codebase, but modules with clear domain boundaries that could be extracted later if needed. It moves faster early, stays debuggable, and doesn’t box you in.
We start extracting services when a specific pain point shows up: a team that’s genuinely blocked on shared deploys, a component that needs to scale independently, something that needs a different runtime. We pull that one piece out and treat it as a service. We don’t decompose everything at once.
The pattern we avoid: choosing microservices because it sounds like the mature choice, or because Netflix does it. Netflix has thousands of engineers and a decade of Kubernetes experience. That context doesn’t transfer. Build for the problems you have now.
Decision checklist
- Team under 15 engineers? → Monolith
- Product still pivoting or finding shape? → Monolith
- Teams actively blocking each other on deploys? → Microservices
- Parts of the system with dramatically different scaling needs? → Microservices
- Need fault isolation between critical components? → Microservices
- Strong CI/CD and platform engineering already in place? → Required before Microservices
If you land mostly on monolith, start there. A well-structured monolith is straightforward to extract from later. Untangling a microservices system drawn up too early is one of the more expensive migrations you can do.