It seems to me that was a classic case of "Microservices done wrong". Yes, splitting the destinations to be able to scale independently makes sense but doing so

It seems to me that was a classic case of "Microservices done wrong". Yes, splitting the destinations to be able to scale independently makes sense but doing so in different repos AND with shared libraries of business logic, that is just bad engineering (and I've done that my self, and I'm doing bad engineering choices every day). Microservices fits nicely when you have identified the appropriate domains of your system and you want to give these domains the freedom to take their own path, independently from the others. In your case, especially when talking about that many destinations a.k.a. services, I would have split them up in different deployments, keep them in a monorepo from the beginning so they can share common infrastructure code (not business logic) but they would be able to have their own logic so engineers could change a field in one that wouldn't affect another one (always doing backward-compatible changes, never removing fields, etc). We live and we learn. Thank you for your post. :)