Not everything has to be a microservice

For a while, when I was learning backend work, microservices looked automatically like the better architecture. Separate services, separate databases, Feign clients, Docker containers — on a diagram it all looks more serious.

Then, working with real systems, I started to see the other side. A separate service also means a separate deployment, network communication, failure scenarios, logging and monitoring.

A service boundary is not a technical question

The hardest question is not “how many services should we create?”. It is “why do these two parts need to live apart?”

If two modules share the same business rule, constantly ask each other for data and change together, splitting them just to have microservices does not settle much.

The opposite holds as well: when the boundary is right, the split earns its keep. Each service carries its own responsibility and has no need to know the internals of the other.

How I approach it now

First I understand the system. Then I separate the modules. Only after that do I think about which part is worth making a service of its own.

Because good architecture is not the architecture that uses the most technology. It is the one that hurts least when change arrives.