SettleMint
ArchitectureComponentsInfrastructure

Chain Gateway

The Chain Gateway provides application-aware load balancing across blockchain nodes, supporting both public networks and private consortium deployments with intelligent routing, failover, and performance optimization.

Overview

The Chain Gateway manages all outbound blockchain connectivity. This component load balances across multiple RPC endpoints, handles failover automatically, and optimizes request routing based on operation characteristics.

Production blockchain deployments require more than single-node connectivity. Node maintenance, network partitions, and capacity limits demand resilient multi-node architectures. The Chain Gateway provides this resilience transparently to application code.

Architecture

Rendering diagram...

Load balancing strategies

StrategySelection criteriaOptimal for
Round robinSequential distributionHomogeneous node pools
Latency-basedLowest response timeGeographic distribution
Health-weightedHealthy nodes preferredMixed reliability pools
Operation-awareWrite to primary, read to replicasRead-heavy workloads

Health monitoring

The gateway continuously monitors node health through:

Block height tracking: Nodes significantly behind chain head mark as degraded.

Response latency: Slow nodes receive reduced traffic allocation.

Error rate monitoring: High error rates trigger temporary removal from pool.

Connection testing: Periodic probes verify connectivity independent of traffic.

Network support

Public networks

Public network connectivity uses multiple RPC providers for redundancy. The gateway abstracts provider differences behind consistent interfaces.

Network typeConfigurationFailover behavior
Ethereum mainnetMultiple RPC providersAutomatic failover
PolygonProvider plus self-hostedPrefer self-hosted
ArbitrumProvider plus sequencerSequencer for writes
TestnetsProvider endpointsBest-effort routing

Private networks

Private consortium networks connect through self-hosted or managed nodes. The gateway supports:

Besu networks: Enterprise Ethereum with permissioning and privacy features.

Custom chains: Application-specific chains with modified consensus.

Air-gapped deployments: Isolated networks without external connectivity.

Performance optimization

Connection pooling

Persistent connections to nodes eliminate connection establishment overhead. Pool sizes scale based on traffic patterns and node capacity.

Request batching

Multiple read requests targeting the same node batch into single RPC calls. Batching reduces network round trips and improves throughput.

Response caching

Immutable data caches locally. Block data, transaction receipts, and historical state cache with appropriate TTLs. Cache invalidation triggers on chain reorganizations.

Retry optimization

Failed requests retry on alternate nodes rather than immediate retry to the same node. This behavior accelerates recovery from node-specific failures.

Failover handling

Node failures trigger immediate failover:

  1. Health checker detects failure through error threshold or probe failure
  2. Load balancer removes node from active pool
  3. In-flight requests redirect to healthy nodes
  4. Recovery probes continue until node returns to health
  5. Recovered node gradually receives traffic

Failover completes in seconds without application awareness.

Metrics and observability

The gateway exposes operational metrics:

  • Request counts by node and operation type
  • Latency percentiles per node
  • Error rates and types
  • Node health status history
  • Pool composition changes

Metrics integrate with the observability stack for dashboards and alerting.

See also

On this page