[forgottenpass]

>They help teams manage complex interdependencies by creating strong ownership boundaries, strong product definition, loose coupling, and allow teams to work at their own velocities and deployment cadences.

You just described library boundaries. You did not describe why the interface has to be a socket.

>the average engineer doesn't need to know about the eventually consistent data model of your active-active session system

People can create unnecessarily connections between microservices too. It's only slightly harder than punching an extra hole through the public interface of an in-process API. Is that what we're spending so much time and money on.

[cousin_it]

Yeah. I think services are mostly needed when you need to scale things independently. If you just need to develop things independently and deploy them on different schedules, you can use a plugin architecture (hotswap dlls or jars into your big app) instead of services. That lets you avoid sockets and use local synchronous APIs for communication. I've worked on a large app with many teams building their own plugins, it was nice.