Sticky routing based on next-uri fields

[shk3]

Hi folks,

Have we considered rewriting next-uri and info-uri directly from the responses in order to achieve query-level sticky routing?

The idea is kinda similar to Trino Proxy, where Trino Gateway proxies all requests. Then we bind the URLs in the following ways:

• /v1/...: handled by the current logic and proxied to one of the Trino coordinators based on whatever load balancing algorithms of choice. In the response, we rewrite the next-uri / info-uri to something like /backend1/v1/... that is directly pointing to the particular backend (or rewrite the X-Forwarded-* headers to achieve the same goal).
• /backend1/v1/...: directly proxied to backend 1 (but block POST to /v1/statement so that queries can only be submitted via the load balancer);
• /backend2/v1/...: directly proxied to backend 2 (but block POST to /v1/statement so that queries can only be submitted via the load balancer);
• ...

With this approach, for query-level sticky routing, we don't need to track which backend each query id gets assigned to. Instead, such assignment is retained on the client side.

The caveat is that for the Trino UI, we would need to develop a way for users to do a combined search queries across all backends as well as a summary of all backend's stats.

Has this approach been considered in the past? We could eliminate the dependency on the databases / caches. If cross-regional networking could be a concern, we could even change the URLs with different domains to avoid inter-regional proxying.

I know Trino Gateway's architecture is pretty much set, so it's not necessarily something we have to do now, but mostly a discussion just in case later on it's needed.

George