RPC Latency

Overview

RPC Latency is the elapsed time between sending a remote procedure request and receiving its response, measured at a defined observation point. It can include client queuing, network transit, provider processing, node execution, and response transfer. For RPC Latency, the client should retain chain, method, block or transaction reference, provider response, and the final on-chain observation.

The main risks include averages hiding tail latency, mixing unlike methods, client-side queueing omitted from measurement, and provider dashboards that exclude failed calls. Provider failover for RPC Latency should not create a second transaction or replace a verified chain result with stale node data.

In production, teams should define ownership and apply method-level histograms, percentile reporting, timeout correlation, region labels, cold-versus-warm separation, and trace propagation. It should be measured by method and network because a simple chain ID query and an archive log query have very different expected costs.

Useful measures include p50, p95, and p99 latency by method, timeout rate, queue time, and latency-related failover count. RPC Latency is closely connected to RPC Monitoring, RPC Timeout, and Dedicated RPC Endpoint. The RPC Latency implementation should distinguish node acceptance, transaction broadcast, execution, confirmation, and indexed visibility where those stages apply.

When nodes disagree during RPC Latency, the application should preserve both observations and defer irreversible action until the authoritative chain state is clear.

The RPC Latency recovery procedure should distinguish a rejected RPC call from a transaction that was broadcast but not acknowledged. Testing RPC Latency should include provider disagreement, reorganization or indexing delay, malformed data, and an unavailable node when relevant to the method.