Hello and I hope you're feeling well.
I'm a fairly novice engineer and my experience with attempting to build microservices has been plagued with the following problems:
- Request/Response for service communication with a 'n' number of services has often led to a huge ball of a system with n:n message connections.
- Introducing an event driven style meant adding a layer of indirection (message queue, event log), complexity in logic in terms of aggregation and sequencing, and the emergent behavior of the system becoming harder to "learn" and understand.
- A gradual loss of abstraction as new business requirements often lead to having to share/fetch state between services AND a gradual muddling of initially defined service responsibilities.
Any advice would be appreciated but I do have more specific questions if that may help:
- How to design service boundaries and responsibilities that will endure new business requirements?
- In a request/response communication style, how does one avoid the "distributed monolith" conundrum?