Sharing code or reinventing the wheel repeatedly is inevitable once you have more than one concern by which you can divide services. For example: let's say you

Sharing code or reinventing the wheel repeatedly is inevitable once you have more than one concern by which you can divide services. For example: let's say you have lots of integrations, and you need to scale compute, and parse and generate common data sent to and from the integrations. You can either have a monolithic integration service which you scale out on load; or you can have integration-specific services that scale out on load and share your data parsing & generation library. Due to multiple concerns, there's no "best slice". FWIW, scaling out compute is a stronger argument to me for a service boundary than responsibility segregation. Scaling out requires distribution; scaling up complexity doesn't, though it can help for other reasons, like CI/CD. I prefer FaaS architectural patterns with the freedom to share libraries in different functions (images) to services, especially if long-running state is not needed.