RPC rate limits: budget requests and handle overload

One plan can impose several different limits

A service can allow a monthly credit budget while also limiting requests per second, simultaneous connections, expensive methods or a particular API group. Remaining monthly credits do not guarantee that a burst will be accepted.

Helius documents separate RPC and enhanced API capacities and credit charging. Other providers define their own groups. Inspect the contract for each method you use instead of assuming that every HTTP call costs one interchangeable unit.

A WebSocket connection and a batch request need their own treatment. A batch containing ten RPC operations is not automatically one billable or rate-limited operation. Read the provider's batch rules and response semantics.

Record which limits apply to a project, key, IP or account. Several services sharing one key can compete for the same allowance even if each process looks modest by itself.

Calculate the workload before choosing a plan

Take a chosen workload: 100 watched addresses, each with one balance request every ten seconds. That is 10 calls per second, 600 per minute and 864,000 per day if it runs continuously. Over 30 days it becomes 25,920,000 calls.

This arithmetic counts requests only. Multiply each method group by its documented credit cost to estimate the billed workload. History pagination, retries, health checks and account discovery add more.

If the screen needs only current values for active users, polling every address all day may be unnecessary. Cache a suitable recent result, stop hidden-screen polling and coalesce identical requests where the application's freshness requirement permits.

Keep the chosen ten-second interval visible as an application assumption. It is not a recommended universal refresh rate or a claim about Solana's processing speed.

Bound concurrency and share reusable results

A small queue can enforce a service-wide request budget. Set a concurrency bound and control starts per time window; a concurrency limit alone can still generate too many fast calls per second.

Give interactive reads and background history jobs separate priorities. Otherwise a large backfill can consume the capacity needed to show a user whether a current payment settled.

Cache by meaningful request identity: cluster, method, address, parameters and required commitment. A balance from another cluster or weaker observation does not satisfy the same query. Define how stale each screen is allowed to become.

Deduplicate in-flight identical reads. If ten components request the same account at the same time, one shared promise can prevent ten separate calls. Invalidate or refresh the cache when the relevant state changes.

Control request starts and retry work

Retry a transient read without creating a traffic storm

Inspect the HTTP status and provider error contract. For throttling, respect Retry-After where supplied. Use increasing delays with random jitter, a maximum number of attempts and an overall deadline.

For illustration, choose waits around 0.5, 1 and 2 seconds before three retries, with random variation. Those are teaching values. The actual policy should fit the endpoint's limits and the screen's latency budget.

Do not retry a malformed parameter unchanged forever. Authentication failure, an unsupported method and an invalid address require a different response from temporary overload.

Ensure only one layer owns the overall retry budget. An SDK making four attempts inside a worker which also makes four attempts can multiply one intended request into sixteen deliveries.

Treat transaction delivery as an uncertain outcome

A send timeout can occur after the service received the transaction. Preserve the original signature, signed bytes and validity boundary. Query its status while following a bounded delivery policy.

Do not convert every timeout into a newly signed transaction. That creates a new transaction identity and may repeat the economic action. Payment workflows need application-level idempotency as well as transport retries.

Separate the queue for valid transaction delivery from historical reads. Dropping time-sensitive delivery behind an hours-long backfill can waste its validity window.

Failover should preserve cluster, commitment and intent. A second provider's older view or missing archive response needs interpretation rather than silent acceptance as the newest truth.

Measure successful work and stale output

Track method-level request counts, latency, throttles, RPC errors, retry attempts and credit estimates. Include queue delay: an endpoint can respond quickly after a job has waited too long locally.

Expose stale or unavailable data in the product. Keeping an old balance on screen without its observation time makes a capacity failure look like a fresh result.

Recalculate the budget from measured usage after launch. User activity, history depth and cache hit rate determine the actual workload. The history guide explains why backfills need a separate plan.

Common questions