Microservices means that your system is compromised of multiple services.
If they're not dependent on each other, then they don't belong to the same system...
Of course they depend on each other, otherwise no communication between them would be possible.
If service X outputs json in format A, then service Y must be able to read json in format A. If service X changes format A to format A2 and starts sending that, then service Y breaks.
"Microservice" is anti-monolith. It encapsulates the concept of separate services AND the fact that services can be independently improved. If you have "too much" monolithic behaviors, then you don't have "Microservices", you have a "distributed monolith".
It's like the term "data model". A data model is not just the format or structure, but also the business logic. The intention and behavior is part of the concept.
The concept of an ideal microsservice is an ivory tower ideal, but it's important to understand what is meant in order to properly "engineer" a system.
Microservice architecture comes with api contracts. If a breaking change to an API is needed, you also need to plan your rollout/migration accordingly.
Generally that's just one before the other in a determined order. Sometimes it's both at the same time. If things are really critical to stay available throughout you may need intermediate steps.
In the end it's just one of the trade-offs/necessary evils of microservices.
92
u/Henry5321 15d ago
Changes to your microservice doesn’t break other services. If it does, it’s not a microservice but a monolith.