I have watched teams spend months splitting a perfectly good monolith into microservices, only to end up with a system that is harder to develop, harder to debug, and slower than what they started with.
Microservices are not inherently better. They are a solution to specific problems. If you do not have those problems, you are just adding complexity.
What is a monolith?
A monolith is a single application. All your code lives in one codebase and deploys together. The frontend, backend, and database access are all in one place.
This is how most successful companies started. Amazon, Netflix, Airbnb — all monoliths at first. They only split into microservices when the monolith became genuinely painful to work with.
A monolith is not a bad thing. It is simple. You can run it locally with one command. You can refactor across the whole codebase. You can trace a bug from the UI to the database in one place. Deployment is one pipeline.
What are microservices?
Microservices split your application into small, independent services. Each service handles one business area — users, orders, payments, notifications. They communicate over APIs or message queues.
The appeal is real. You can scale the orders service independently from the user service. Different teams can work on different services without stepping on each other. A bug in the notification service does not take down the whole app.
But the cost is also real.
What microservices actually require
To run microservices properly, you need:
- Container orchestration (Kubernetes or similar)
- Service discovery (how does service A find service B?)
- Distributed tracing (how do you debug a request that touches 5 services?)
- Centralized logging (logs from 20 services need to be in one place)
- API gateways
- Multiple deployment pipelines
- A team that understands all of this
This is a lot of infrastructure. A small team cannot manage it well. I have seen startups with 5 developers running 15 microservices. They spent more time managing infrastructure than building features.
The modular monolith: the best of both
There is a middle ground that most teams should consider: the modular monolith.
You organize your code into clear modules with defined boundaries — a Users module, an Orders module, a Payments module. Each module has its own folder, its own service classes, its own database tables. But they all deploy together as one application.
When you eventually need to split a service out, the boundaries are already there. The migration is much easier.
When to actually use microservices
Microservices make sense when:
- You have 50+ engineers and coordination is genuinely painful
- Different parts of your system have wildly different scaling needs
- You have mature DevOps practices and dedicated platform engineers
- Your monolith has become genuinely hard to work with
For everyone else: start with a well-structured monolith. Build your product. Get customers. When the monolith becomes a real problem, you will know — and you will have the resources to fix it properly.
