When microservices make sense — and when they don't

Microservices solve specific problems. Adopted too early or too broadly, they create a distributed monolith with network latency, complex observability requirements, and a vastly increased operational surface area.

The case for microservices

Microservices are genuinely valuable when: you have independent teams that need to deploy independently, you have components with dramatically different scaling requirements, or you have a genuine need to use different technology stacks for different capabilities.

The case against (and when to wait)

If your team is small, your domain is poorly understood, or your monolith is well-structured and performing adequately — you almost certainly don't need microservices yet. The operational overhead of running dozens of services is significant, and the domain knowledge required to draw the right service boundaries takes time to develop.

The strangler fig pattern gives you a middle path: extract services incrementally, as your understanding of the domain matures.