Priority failover
Follows configured order. Use it when one upstream is preferred and the rest are backups.
RPC load balancing
A Route picks one Endpoint per request, by configured order or by relative weight. Both strategies filter candidates before any upstream call.
Each Route carries one selection strategy. Priority failover walks the Endpoint order you configured and only moves on when a target is unusable. Load balancing draws one eligible candidate at random by relative weight. The choice changes which Endpoint is tried first; it does not change what happens after a failure, because both strategies apply the same candidate filter and the same Circuit admission before any upstream call is made.
Follows configured order. Use it when one upstream is preferred and the rest are backups.
Selects by relative weight. Use it when the targets are interchangeable for the traffic on that Route.
Disabled or mismatched Endpoints are filtered out first, and Circuit can reject the selected candidate.
Normalized weights describe expected shares of initial selections while the eligible candidate set stays the same. Short samples vary, and that is normal for random selection. When a filter, a Circuit rejection, or a retryable failure removes a candidate, the remaining weights renormalize, so real upstream attempts can depart from the configured shares during an incident. A single remaining candidate is still selectable, which is why weighting is a distribution tool rather than an availability guarantee.
Weights set expected shares of initial selections, not a fixed rotation over a fixed number of requests.
Losing a candidate redistributes its share across the targets still eligible for that request.
A selected Endpoint leaves the pool for that request, so the same upstream is not attempted twice.
A Gateway has a default JSON-RPC Route, and you can add method Routes that select a different Endpoint set for named methods. That is how a trace or debug workload gets its own upstreams while ordinary reads keep using the default Route. Methods you do not name fall back to the default Route, and a Route accepts at most 100 targets, so the split stays explicit rather than inferred from traffic.
Give interchangeable targets the same weight first, and change one weight at a time so you can attribute what changed. Every Endpoint lists the active Routes that reference it, including the strategy, the method scope, and the target count, which is where you check what a weight change will actually touch. Route updates carry an expected version, so a concurrent edit fails instead of silently overwriting a newer configuration; reload the Route and reapply rather than forcing the write.
Selection reads your configuration, not the network. Reported latency and health status are observational and are not inputs to the strategy, and the Gateway does not compare chain tips, block heights, or upstream pricing before choosing. There is no connection-count or round-robin mode. Runtime protection comes from Circuit, which removes a failing Endpoint from selection and admits a probe after a cooldown, and Circuit state is shared runtime state that admits the request when it cannot be read.
Next step
Open the Gateway Route that already has more than one matching target, choose priority or weighted selection, and set the weights you want to start from.