Client access algorithm with multiple overlapping services

I am looking to understand the following use-case:

A ziti network has two services:

  • The intercept and host configs overlap (i.e. the same FQDN or IP can be intercepted on both services).
  • There is a completely disjoint set of reverse-proxy routers and edge-routers attached to the two services via the bind service-policy and the service-edge-router-policy
  • A client has access to dial both services and it is allowed to access both sets of edge-routers via its edge-router-policy.

In this case, when the client attempts to reach an endpoint that can be intercepted by either service, which service will be used to establish the connection?
More specifically, will the client always transport data to this endpoint via the edge-router closest to it by latency (from all the edge-routers belonging to both services)?

This is a very bad situation. I believe this will result in non-deterministic behavior where depending on how it starts up, you'll get one service or the other. You don't want two services that one identity can dial to be able to dial both. This is something we sometimes refer to as "conflict detection" and determining it dynamically at the controller is very, very hard and at the client is "doable" but also quite hard. We have worked on discovering a good way of determining this, but it's not a high-priority problem for us to solve. It's generally a "yeah, don't do that" sort of thing, unfortunately.

I'm pretty sure this will be entirely non-deterministic behavior.

Got it @TheLumberjack .
Thank you.

Are these services actually same, i.e. provide equivalent functionality to the client?

Are you trying to implement some kind of geolocation routing -- like routing a client connection to closest data center?

In that case you want to make it a single service that is hosted in various locations. Then SDK/smart routing will connect you to the closest(based on latency) data center.