How we built low-latency RPC infrastructure

A wallet loads a user's balance. A trading app estimates gas before a swap. An indexer backfills months of history in a single burst. Every one of those actions is an RPC call, and every millisecond of delay is felt by a real person waiting on a screen.

RPC latency is not caused by one thing, so it cannot be solved by one thing. It comes from request-path overhead, avoidable internal network travel, inefficient routing, sudden traffic spikes, chain and node operational lag, workload-specific bottlenecks, and incomplete measurement. Fixing one and ignoring the rest just moves the bottleneck. So we treated latency as a system problem and invested across every layer we control, holding 99.99% uptime and sub-50ms average response times as the baseline across the 100+ chains we support.

What we built

Alchemy Edge Proxy reduces request-path overhead

The edge is the front door: the first Alchemy-controlled entry point a request touches. Before a call reaches any node, it passes through connection setup, TLS negotiation, authentication, and routing logic. Each step adds milliseconds, and those milliseconds stack up most at the tail - the slowest requests, the ones a user actually feels.

Alchemy Edge Proxy is the layer we built to strip that overhead out of the request path. By handling connection reuse, auth, and routing decisions at the front door instead of deeper in the stack, it cuts the fixed cost every request pays. The result is up to 7.5x faster RPC at the tail. See Alchemy Edge Proxy for a deeper look.

Under the hood, the edge runs on a microkernel proxy architecture, part of Cortex: a small, stable core owns the critical request path, while modules like authentication, rate limiting, and routing are updated independently. Because the edge is one of the critical infrastructure layers we control end to end, we can keep improving it without waiting on anyone else's network.

Inside our infrastructure: closer placement, smarter routing, steady throughput

Once a request is inside our infrastructure, distance and hardware still cost time. If the services that handle a call sit far apart, the request spends milliseconds just traveling between them before any real work happens. And when volume climbs, shared hardware adds the kind of variability that shows up as inconsistent latency.

This is where Cortex, Alchemy's intelligent blockchain engine, does the heavy lifting. Cortex is the core infrastructure investment behind our low-latency numbers, and a few specific pieces of it matter here:

• Pod colocation with Kubernetes affinity keeps the services that talk to each other most on the same machine, so requests stay local instead of hopping across racks.
• Istio locality-aware routing sends internal traffic to the closest available service instance, shortening infrastructure paths when doing so actually helps.
• Thousands of globally deployed bare-metal servers run directly on dedicated hardware with no virtualization overhead, so throughput stays consistent under heavy load.
• Java virtual threads let a single machine handle far more concurrent requests without the memory and CPU cost of traditional threads, which is what absorbs a surge without latency climbing.

Together they cut the travel time users never think about but always feel, and hold performance steady as volume rises.

Predictive scaling prepares capacity before spikes

Onchain traffic does not ramp politely. A launch, a mint, or a market event can multiply load in seconds, and capacity that arrives after the spike is capacity that arrived too late.

Our predictive scaling logic prepares capacity ahead of demand instead of reacting to it, watching signals like CPU, memory, disk I/O, and traffic patterns to provision before a spike lands. Usual is the proof: they peaked at 30,000 requests per second, served 38 million requests in the first hour, and crossed 1 billion requests in 36 hours, without latency falling apart under the surge.

"Alchemy was able to give us a near perfect availability, serving massive amounts of requests per second (30k requests per seconds was our peak, and we still had buffer), without any hiccups or downtime. And all on short notice!"

Adli Takkal-Bataille at Usual

AI-managed fleet automation keeps node operations current

Blockchains change underneath you. Clients ship updates, networks schedule hard forks, and a node running stale software is a node serving slow or wrong answers. Handling that by hand introduces delay and risk exactly when precision matters most.

Our node fleet is managed by a fully automated agentic system that handles upgrades, testing, and monitoring. Updates are detected and applied in real time, with automated testing built into the pipeline, so mandatory network upgrades and hard forks are never missed. Doing this by hand across every chain we run would be impossible to keep current - which is why we automated it, and why we hold the same low-latency bar across 100+ chains instead of a favored few. This automation is part of Cortex, the intelligent blockchain engine behind the Alchemy platform: RPC APIs, data APIs, rollups, and the rest of the developer stack.

Product-specific optimization improves full user flows

Latency is not only about a single call. Real products chain calls together, and the flow is only as fast as its slowest link. What users actually feel is the whole path, not any single method.

World, built by Tools for Humanity and running on World Chain, saw a 44% faster time to mine, from 5.5 seconds down to 3.1 seconds, and 74% lower gas-estimation latency on alchemy_requestGasAndPaymasterAndData, from roughly 380ms to 100ms.

"When we were searching for infrastructure vendors, what mattered most was enterprise scale and support. Alchemy was hands down the clear leader across every product we needed-the only logical choice."

Steven at Tools For Humanity

Solana archival infrastructure reduces heavy-query latency

Historical and archival queries are their own kind of hard. Pulling large ranges of past state is heavy work, and on a chain as high-throughput as Solana it can crawl without infrastructure built for it. We built the fastest archival methods on Solana on a custom multi-region HBase architecture, part of our Solana platform.

Solflare ran exactly that workload and saw up to 20x faster archive queries, sub-200ms response times during large historical queries, and wallet backfills completing in under a minute.

"Alchemy's Archival RPC has kept up with Solflare's throughput while keeping a consistent <200ms response time."

Dusan K. at Solflare

Benchmark methodology measures speed and reliability together

Speed numbers mean nothing without honesty about what happened to every request. A fast average that hides failed or dropped calls is not fast, it is misleading.

Our benchmark methodology measures latency alongside success rate and failed requests, so the numbers reflect what a real workload would experience. That is the standard we hold ourselves to, and the one we invite you to hold us to. You can review the full benchmark methodology.

The goal: infrastructure fast enough to disappear

The best infrastructure is the kind nobody notices. When latency is low enough and reliability is high enough, the wallet just loads, the swap just confirms, and the backfill just finishes. No layer of this stack solves latency alone, but together they add up to that experience.

See the numbers for yourself. Compare providers on the Alchemy benchmarks page, and read exactly how we benchmark RPC performance so you can judge the method, not just the result. When you are ready to build on it, get started for free.

FAQ

What causes RPC latency?

RPC latency comes from several independent sources: request-path overhead at the entry point, avoidable travel between internal services, inefficient routing, traffic spikes, chain and node operational lag, workload-specific bottlenecks, and incomplete measurement. Because the causes are separate, no single fix removes all of them.

Can one optimization solve RPC latency?

No. Fixing a single cause simply shifts the bottleneck to the next one. Reducing latency reliably requires investing across every layer of the request path, from the edge down to the node infrastructure and the way performance is measured.

What is the edge in RPC infrastructure?

The edge is the first provider-controlled entry point a request reaches, the front door for RPC traffic. Handling connection setup, authentication, and routing there instead of deeper in the stack removes fixed overhead every request would otherwise pay.

How does Alchemy measure RPC latency honestly?

Alchemy measures latency alongside success rate and failed requests, not as an isolated average. This prevents a fast-looking number from hiding dropped or failed calls, so the results reflect what a real production workload would actually experience.

How does predictive scaling handle traffic spikes?

Predictive scaling prepares capacity ahead of demand rather than reacting after a spike begins. This is what let Usual sustain 30,000 requests per second and over 1 billion requests in 36 hours without latency degrading during the surge.

Why is Solana archival query performance a separate problem?

Archival queries pull large ranges of historical state, which is heavy work, and Solana's high throughput makes those ranges even larger. Purpose-built archival infrastructure is what keeps these queries fast, as seen with Solflare's up to 20x faster archive queries.