Skip to content

RPC load balancing

Share RPC traffic across the upstreams you already have

A Route picks one Endpoint per request, by configured order or by relative weight. Both strategies filter candidates before any upstream call.

Open consoleCompare both strategies

Two strategies, one decision per Route

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.

Priority failover

Follows configured order. Use it when one upstream is preferred and the rest are backups.

Load balance

Selects by relative weight. Use it when the targets are interchangeable for the traffic on that Route.

Shared admission

Disabled or mismatched Endpoints are filtered out first, and Circuit can reject the selected candidate.

Compare both strategiesExplore RPC failover

What weighted selection actually promises

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.

Expected, not exact

Weights set expected shares of initial selections, not a fixed rotation over a fixed number of requests.

Renormalized on removal

Losing a candidate redistributes its share across the targets still eligible for that request.

One request, one target

A selected Endpoint leaves the pool for that request, so the same upstream is not attempted twice.

See when a candidate is rejectedSet the attempt bound

Split heavy methods onto their own targets

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.

Attach targets to a RouteBring more upstreams in

Start even, then adjust deliberately

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.

Inspect Route bindingsAdd vendor targets

Where the balancing stops

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.

Read what health data coversMix in a self-hosted node

Next step

Set a strategy on one Route

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.