4 ms·

Then your beautiful microservice gets old and requirements change. Now you have to fix 15 different services, rework interfaces, coordinate with multiple teams.

Then your beautiful microservice gets old and requirements change. Now you have to fix 15 different services, rework interfaces, coordinate with multiple teams. My golden rule is: if you can’t do a monolith right, you will fail even more at microservices. I think moving some parts into services but I see a lot of simplistic “we have users, so let’s do a user service. Then we have files, so let’s do a file service”. This will become a maintenance nightmare in my view.

jimbokun 1y ago
No you can update ONLY the micro services that are impacted by the new requirements without impacting the other micro services. > “we have users, so let’s do a user service. Then we have files, so let’s do a file service”. Agreed that this is not a useful heuristic for deciding how many services you need.
- SAI_Peregrinus 1y ago
  > No you can update ONLY the micro services that are impacted by the new requirements without impacting the other micro services. Only if the new requirements don't require a breaking API change. Microservices make API breaks more difficult, since they're loosely coupled it's harder to find all users of an old API & ensure they're updated than it is with a tightly-coupled system. Microservices make non-breaking changes easier, and help ensure all access is gated through an API.