When are microservices not justified?

Microservices are not justified when the system has not yet reached the scale at which their benefits outweigh the costs. In a number of cases it is simpler and safer to start with a monolith.

#1. Small project or startup

When the product is still taking shape, requirements keep changing, and the team is small, microservices only add complexity. A monolith is faster to launch and easier to maintain.

#2. No DevOps infrastructure

Without CI/CD, containerization, and monitoring, managing many services by hand is impossible. Microservices without automation quickly turn into chaos.

#3. Small team

If there are few developers, splitting the system creates more communication and technical barriers than benefits.

#4. High requirements for data consistency

When business processes require strict transactions (for example, banking operations), distributed services complicate implementation and raise the risk of errors.

#5. No clear domain boundaries (bounded contexts)

If business areas are not separated, services start overlapping and depending on each other - this is no longer microservices, but a "sawn-apart monolith".

Summary:

Microservices are justified at large scale, with mature processes and a clear domain structure. In the early stages or with small teams, it is better to start with a simple monolith and split out services gradually.