Thank you! We're really excited about covering the entire dev lifecycle using this approach. Re: routing, do you make use of a library that is directly included in each service? We've seen an approach in the wild where such logic is embedded into gRPC interceptors and HTTP middleware. Curious to hear how you thought about the choice between that and using the mesh.

Right now, we just require intermediate services to be spun up if you need to connect with a custom downstream service.

So, as an example, if I have three services where A talks to B, B talks to C, and I have a custom version of A & C that require testing E2E, we have to spin up B in the middle.

It definitely is a point of confusion for engineers who have to understand what intermediate services are in play when working on a frontend and some distant backend microservice. Fortunately, that intermediate layer tends to just always be the same two services, so folks learn pretty quickly. At scale, especially hyper-scale in a microservices architecture, this becomes untenable, and either automatic dependency discovery OR routing (like you designed) is the path forward.

Needless to say, it's a "niche" issue I think folks don't run into for a while in their setups; however, once you run into it, it's a PIA for those involved.

Makes sense. I have seen a couple of instances of this pattern - with service dependencies being stitched together using configuration. Thanks for sharing!