The problem: every request has a context
A global application cannot treat every region as interchangeable. A request arrives with a destination, a protocol, a deployment version, and an implicit network path between the user and the infrastructure. Apex models those inputs separately, then makes the smallest routing decision necessary for the request.
The important design choice is to keep the control plane out of the hot path. Deployment metadata, health state, and routing policy are distributed ahead of time so an individual request does not wait for a central service.
Three signals drive the route
- Project policy: host, path, environment, and deployment rules narrow the eligible targets.
- Health: regions advertise readiness only after runtime, certificate, and dependency checks pass.
- Network proximity: the router prefers a healthy region that is close to the request without violating the project policy.
Failover is a routing decision, not a redeploy
When a region becomes unhealthy, Apex does not rebuild the application. The current deployment remains immutable while the route table stops advertising the failed target. That separation means recovery is faster and easier to audit: the artifact did not change, only the set of eligible execution locations did.
Global distribution should reduce operational choices, not create another system for the team to babysit.
How to observe routing in production
The deployment view exposes region health, request volume, error rate, and route decisions. For incident analysis, logs retain the deployment ID and region code so teams can correlate an application error with the exact execution location.
Put the routing model into practice
Use the deployment and architecture guides to decide what belongs at the edge and what should remain in your primary data region.