[Feature Request] - Support Multiple Backend Endpoints with Built-in Load Balancing & Health Checks

[breezytm]

Summary

We would like to request support for configuring multiple backend service endpoints instead of a single backend URL.

Currently, the backend configuration accepts only one endpoint. In high-availability deployments(such as relayer + miner), this creates a single point of failure and requires external infrastructure (e.g., NGINX, HAProxy) to perform backend load balancing and failover.

Allowing the application to natively manage multiple backend endpoints would significantly improve resilience and simplify deployment architectures.

---

Proposed Configuration

Support a comma-separated list of backend endpoints:

services:
   eth-mainnet:
      default_backend: jsonrpc
      timeout_profile: fast
      backends:
          jsonrpc:
             url: "http://eth-node1: 8545, http://eth-node2:8545"

---

Proposed Load Balancing Methods

Support selectable load balancing strategies:

      backends:
          jsonrpc:
             url: "http://eth-node1: 8545, http://eth-node2:8545"
             method: least_conn

Supported values:

• round_robin (default)
• least_conn
• ip_hash

---

Health Checks

Each backend endpoint should be actively health-checked using a configurable HTTP path.

This health check could follow a path-based approach similar to:

https://github.com/pokt-network/pocket-network-resources/blob/main/pocket-health-checks.yaml

Example:

  checks:
    - name: eth_blockNumber
      type: json_rpc
      method: POST
      path: /
      body: '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
      expected_status_code: 200
      timeout: 5s
      sync_check: true

---

Failure Handling

If a backend endpoint begins returning 5xx responses:

• It should be automatically marked as unhealthy and removed from the active load balancing pool.
• Periodic health checks should continue in the background.
• Once the endpoint responds successfully with a 2xx status code, it should be automatically re-enabled in the pool.

---

Benefits

• Removes dependency on external load balancers for backend redundancy
• Simplifies HA deployments for relayer and miner stacks
• Provides built-in fault tolerance
• Improves session reliability and relay success rates
• Enables better multi-host deployment patterns

---

Use Case

In deployments where multiple backend full or archival nodes are available across different hosts or regions, this would allow:

• Native failover if a backend becomes unavailable
• Balanced traffic across backend services
• Seamless recovery without manual intervention

---

Thanks for considering this feature request!