SebastianVerified account

Utilizing a micro-service architecture within a monorepo source depo mitigates the majority of pitfalls associated with code sharing and cross service breakages.

Pairing this approach with a shared backwards compatible api interface schema declaration (see protobuf) ensures that rolling deployments of a subset of services will not break your existing service stack due to new or unknown api shape.

When your architecture scales past 5+ services with dedicated teams and dedicated roadmaps it is naive to assume that cutting and rolling releases from tip of tree is possible.

Even ignoring percentage based canarying or rollouts of your new service releases, ensuring a shared backwards compatible api contract is one of the most important aspects of building a multi-layered system that is robust against N service rollbacks/rollforwards

Regardless If a team decides to follow a single monoservice architecture or a multi-servive approach, the fact is at anything past 1 instance you will be running multiple versions of your release build, and there will be rollbacks which will expose any hard coded schema decisions