Routing strategies

Every request is scored against the providers whose circuit breaker is closed, and sent to the winner. The strategy on your key decides how that score is weighted.

The strategies

Latency-based (default)

Ranks healthy providers by a rolling p50 measured over the last five minutes, per region, and sends each request to the current leader.

This is the right default for almost every application. Because Prism measures every request from every tenant, its estimate of which provider is fastest right now converges far faster than any single application's could.

The five-minute window is deliberate: responsive enough to follow a real degradation, slow enough that routing does not oscillate between two providers a millisecond apart.

Round robin

Even distribution across the healthy pool. Predictable and easy to reason about. Choose it when every provider is on an identical plan and you care more about spreading quota burn evenly than about shaving milliseconds.

Weighted

You set the split and Prism honours it, skipping unhealthy providers and redistributing their share across the rest:

{
  "strategy": "weighted",
  "weights": {
    "alchemy": 60,
    "quicknode": 30,
    "ankr": 10
  }
}

Useful when you have committed spend with one provider and want most traffic to land there while keeping live failover capacity elsewhere.

Random

Uniform selection from the healthy pool. The cheapest possible decision - no scoring, no comparison. Choose it only when routing overhead genuinely matters more than provider quality, which is rare.

Choosing

Set the strategy per key on the dashboard. It takes effect at the edge within seconds and requires no redeploy.

What every strategy does anyway

Regardless of strategy:

• Providers with an open breaker are excluded before scoring
• Providers below the consistency high-water mark are excluded for that key
• Providers at their quota ceiling are skipped rather than sent traffic that will 429
• A failed read is retried on the next-best provider, not the same one

Consistency and routing

Pooling introduces a hazard a single node does not have: two providers at different block heights. Read height N from a leading provider, then read state from a lagging one, and the chain appears to move backwards.

Prism keeps a per-key high-water mark of the greatest block height it has returned to that key. A provider reporting a height below the mark - beyond a small tolerance for normal propagation - is excluded from routing for that key until it catches up. A provider that stays behind is treated as unhealthy and its breaker trips on drift alone, without a single error being returned.

You get pooled capacity without ever seeing state go backwards.

Seeing the decision

Every response carries the provider that served it and how long the upstream took:

X-Prism-Provider: quicknode
X-Prism-Upstream-Latency: 38
X-Prism-Cache: miss
X-Prism-Attempts: 1

Full header reference in observability. The playground shows the same decisions live.