You must log in or register to comment.
If you’re not deliberately min-maxing the CAP Theorem or doing EDA, there’s no reason to use microservices and every reason not to.
It is not just an implementation detail or a matter of preference. There are fundamental UX implications.
That can be a net positive for users (and developers). But if you’re doing it “just cuz”, you’re gonna have a bad time.
Ugh, this is what our legacy product has. Microservices that literally cannot be scaled, because they rely on internal state, and are also all deployed on the same machine.
Trying to do things like just updating python versions is a nightmare, because you have to do all the work 4 or 5 times.
Want to implement a linter? Hope you want to do it several times. And all for zero microservice benefits. I hate it.
I find what you generally want is a service bus. For example, if you have common tasks like sending emails, making PDFs, etc. you can create generic services that handle the action, and then call them providing the context such as the document the service should operate on. Meanwhile, actual business logic and the state should absolutely live in a single place.
Delivering this feature goes against everything I know to be right and true and I will sooner lay you into this barren earth than entertain your folly for a moment longer!
