Microservices split an application into small, independent services. They can help large teams scale — but for most projects they add complexity that costs more than it returns. Knowing when you actually need them saves a lot of pain.
What they are
Instead of one application (a "monolith"), the system is many small services that talk over the network, each owning one job and deployable on its own. That independence is the whole point — and the whole cost.
What they solve — and cost
- Solve: large teams working without stepping on each other.
- Solve: scaling one heavy part independently of the rest.
- Cost: network calls, distributed debugging, deployment complexity.
- Cost: you now run infrastructure, not just code.
Start with a monolith: almost every successful product began as a well-structured monolith and split out services only when a real bottleneck appeared. Premature microservices are a classic over-engineering trap.
Signs you might need them
Multiple teams blocked by one codebase, one component needing very different scaling than the rest, or parts of the system with genuinely separate lifecycles. If none of these is true, a clean monolith will serve you better and cheaper.