Rules:
Diagram:
┌───────────────────────────────────────────────┐
│ │
│ usa-region-1 │
│ ┌───►/app-1/*│
│ │ │
┌───┼──► Load ──────► ┌── Ingress ────┤ │
│ │ Balancer │ Controller ├───►/app-2/*│
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ └───►/app-3/*│
│ │ │ │ │
│ │ │ │ │
│ │ │ └─Authentication │
User──────► Cloudflare ──────►│ │ │ Service │
Request │ │ │ │
│ └──────────────────┼────────────────────────────┘
│ │ *proxie the request*
│ ┌──────────────────┼────────────────────────────┐
│ │ │ │
│ │ europe-region-1 │ │
│ │ │ ┌───►/app-1/*│
│ │ │ │ │
└───┼──► Load ───────► └── Ingress ────┤ │
│ Balancer Controller ├───►/app-2/*│
│ │ │ │
│ │ │ │
│ │ └───►/app-3/*│
│ │ │
│ │ │
│ └─Authentication │
│ Service │
│ │
└───────────────────────────────────────────────┘
LOCAL DATA STORAGE REQUIREMENT
In some markets, there could be regulatory reasons for keeping a user's data stored within their home region. So if a European user has travelled to the USA, they should continue to be routed to European servers, and their data will remain in Europe.
SIMPLE ROUTING BASED ON HEADERS
First you need something in each HTTP request, such as the user_region
header that you mention. The ingress controller is the logical place to do this, rather than for each service. Here is a Traefik header based routing example.
ROUTING IN INGRESS CONTROLLERS
If you need more complex logic, then a plugin can be written, using either the extensibility features of the ingress controller, or a dedicated API gateway placed in front of APIs. For an example see this NGINX configuration file, which sets the target host name based on this Lua plugin.
FURTHER INFO
These links may also be of interest. In particular note how unauthenticated requests can be handled, by identifying the user first, then transferring the user to their home region so that authentication takes place there. This can allow credentials for users to only be stored in their home region.