When to split into microservices (and when not to)

Microservices get talked about as the cure for every scaling problem. The truth is messier: splitting at the wrong time can kill a startup’s velocity.

The monolith is not the enemy

Most products should start as a well-organized monolith. It is easier to develop, debug and deploy while the team is small. Microservices add operational cost that only pays off once you are big enough.

When to split

• When parts of the system need to scale at very different rates.
• When multiple teams need to deploy independently, without waiting.
• When a business domain is stable enough to draw clear boundaries.

Split services for your organization, not because the diagram looks nice.

— Minh Trần

Our advice: start with a monolith, draw clear module boundaries early, and only split out when the pain is real.