Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are right but from a different context. In a well thought out microservice architecture, you will not have business logic scattered across multiple services.

We have had instances of microservice architecture where doing one change required changes in 4 different microservices defeating the whole point. Obviously this is bad.



“ In a well thought out microservice architecture, you will not have business logic scattered across multiple services.”

A “well thought out” architecture that holds up over years is a pipe dream. There will always be changes that require a rethinking of the whole system.


As the sibling say, the changes of the future are not predictable. The perimeter for business logic or bundled changes change.

Having a monolith much nicer allows to make these types of changes.


Yes that's the tradeoff. Over time your architecture degrades and you need to rethink the services. But good part is that migration is simpler and less risky when you are just making changes to few microservices.


I am curious, how is this the case?

Is that because a failure of a service would only affect a single flow?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: