Solana node under load: where RPC access breaks
When a service on Solana reaches real traffic, the first bottleneck in the infrastructure is not the node itself but RPC access. While there are dozens of requests per minute, everything looks healthy: responses arrive quickly, rejected requests are isolated. As soon as the product grows, the picture changes — and it does not change gradually.
Peak load exposes the queue.
Requests from wallets, the backend, and analytics go to the same access point; no one has prioritized them, so network response latency grows nonlinearly: while the queue is short, responses are instant; once it crosses the threshold, wait time doubles for every next hundred requests. Some requests no longer survive to a response.
Then the cascade begins. A client that receives a rejection retries the request — and the rejected requests themselves become a source of load.
The application shows the user an empty balance, retries occupy connections, and the team looks for the cause in the code, although it lies in the node configuration and in the lack of separation between read and write flows.
This is a typical scenario, and it is resolved at the architecture level, not by installing another node. Let's break down how it works.
What optimization delivers: throughput and fault tolerance
Public RPC is designed for shared traffic and cuts requests by per-address limit: during an activity spike, the client receives rejections instead of data.
A dedicated Solana node removes the quota — throughput is determined by the node's resources, not someone else's plan, so the flow of requests from a wallet or trading module does not sag during peak hours.
Response time is made up of the network path, state lookup in the node's indexes, and the request queue.
We keep a persistent connection instead of reconnecting on every call, cache frequently requested accounts, and route transaction reads and sends along different paths: sends go directly to the current leader rather than into the shared read queue.
Some failures are eliminated not by speed but by topology.
A node that has fallen behind the network by several confirmed blocks returns stale state, and the client makes a decision based on incorrect data — checking by the height of processed blocks and removing such a node from balancing eliminate this class of errors entirely.
The second class is transactions lost to limits and waiting: a backup route and resend reduce the error rate to tenths of a percent.
Fault tolerance is built on several nodes with different providers and in different networks: the load balancer removes traffic from an unhealthy node automatically, without manual intervention.
We measure service stability by the share of error responses, latency at the 95th and 99th percentile, and the share of transactions confirmed on the first attempt — by these metrics, alerts arrive before the user notices degradation.
Solana node deployment options: own server, cloud, hybrid
The deployment scheme determines who is responsible for node fault tolerance and how quickly the volume of state data on disk grows.
A dedicated server gives full control over storage and the network stack, cloud infrastructure gives speed of launch and hardware replacement via API, and a hybrid scheme keeps a hot node close to users while the history archive lives on cheap storage.
The difference shows during connection drops and under growing load: in some setups the node is restarted manually, in others it is recreated automatically. Below are three working schemes and their real limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Dedicated server | Stable request flow, fine-tuning of network and disk I/O, data location requirements | Redundancy and updates are on the team's side; hardware failure causes downtime until replacement |
| Cloud infrastructure | Variable load, fast scaling, replicas in different regions | I/O limits and hypervisor specifics, provider dependency when a zone degrades |
| Hybrid scheme | Peak reads with low latency plus long-term history storage and a backup node | More complex state synchronization and monitoring, unified request routing required |
On top of any scheme, request balancing is added: several nodes behind a single address, health checks for each, and disconnection of any that has fallen behind the network. This removes a single point of failure and allows taking a node out for maintenance without downtime.
How implementation proceeds: from audit to handover to operations
Implementation proceeds in stages, and each ends with an artifact that can be verified: a scheme, a configuration, a test report. A stage cannot be skipped — a design error surfaces only under load, when rework is most expensive. The order of work is structured so that risks are removed at the cheapest stage.
- Infrastructure audit. We look at what exists now: disk headroom, channel throughput, node behavior during network peaks. We take actual metrics rather than rely on words — the gap between what is stated and what is real is usually the root of the problems.
- Scheme design. We define the topology: separate roles for serving requests and for working with the network, failure points, redundancy scheme. The output is a placement plan and a resource headroom calculation.
- Node configuration. We deploy Solana nodes with agreed parameters, move keys into secure storage, and connect metrics collection and alerts for critical thresholds.
- Load testing. We run a synthetic request stream, measure response latency and error rate, then deliberately break the disk and channel — to see how the scheme survives a failure and recovers.
- Handover to operations. We provide documentation, access, and instructions for typical operations, and train the team on a live stand rather than with slides.
- Maintenance regulations. We fix the procedure for zero-downtime updates, backup rules, and the set of routine checks.
After handover, the node remains manageable: the team understands what to do and when, rather than calling the contractor for every issue. After that — support or full autonomy, whichever is more convenient.
What you are left with: configurations, schemes, regulations
Node work does not end with a running process but with a set of artifacts that your team uses to operate it without our involvement. Below is what we hand over in closed form: configurations, schemes, policies, and regulations.
Everything is in a repository under version control, with a description of why each parameter is set exactly this way.
- Environment configurations — launch files, parameter values, memory and connection limits, binding to the current branch. Deployed with a single command, without edits "from memory".
- Network schemes — topology, entry points, request balancing, redundancy. You can see where the bottleneck is and which node fails first.
- Access policies — roles, keys, rotation procedure, restrictions by request addresses and methods. External access is closed, service access is controlled and logged.
- Technical documentation — architecture, dependencies, backup and recovery procedures, acceptance checklist. A newcomer on the team gets up to speed in a day, not a week.
- Incident response regulations — failure levels, on-call duty, procedure, timelines, and escalation points. An incident is closed step by step, without improvisation.
- Monitoring and alerting dashboard — metrics, thresholds, synchronization history. You learn about degradation before users do, rather than from their requests.
- Change log — configuration versions and edit history with justification. Rollback to the previous working state takes minutes.
Separately, we hand over an update instruction: what is checked before restart, what is checked after, and which metrics confirm that the node is back in service.
Case study: how we restored stable RPC access after failures
A service with a growing audience accessed the network through a single Solana node set up back at the prototype stage. During peak hours, users saw timeouts and empty balance responses, and some transactions did not reach confirmation.
In support, it looked like "the network is unavailable," although the cause was the access scheme on our side.
Load measurements showed: the bottleneck was not network throughput but the lack of distribution. All read and write requests went to a single node, without cache and without automatic retries during a brief disconnection. One overloaded node dragged down the entire output.
What the measurements showed
| Metric | Before restructuring | After |
|---|---|---|
| Share of requests with errors at peak | 6–8% | 0.3–0.5% |
| Balance read response | noticeable delays | consistently within normal |
| Node update | interrupted the service | unnoticeable to clients |
| Request retry on failure | manually | automatically |
We restructured the access scheme: a pool of nodes behind a single entry point, health checks for each node before traffic is served, a separate read environment with cache, and priority for confirmed transactions.
Retries and switching between nodes were configured so that the client does not notice the failure of a single node.
The share of errors at peak dropped by more than ten times, maintenance under load proceeds without stopping the service, and stable network access is no longer a reason for support requests.
How a public RPC endpoint differs from dedicated access
A public endpoint is a shared entry point: your calls are processed by the same node as requests from hundreds of other projects. The provider maintains request limits per key and per address, so neighbor activity affects you through rate-limit rejections and exceeded wait times. During quiet hours, such access looks functional — and that is what makes diagnostics harder.
The key difference is not average speed but response predictability. A shared entry point has a long-tail response time: some calls arrive with a delay, the application goes into retries, and retries themselves amplify degradation. The indexer begins to fall behind the network exactly when fresh data is needed most.
Dedicated access removes the neighborhood: separate nodes are reserved for the project, and request limits are set for your load profile, not a shared plan. Throughput is not divided, so response predictability is determined by your traffic.
Additionally, priorities for critical methods and stable node addresses appear, to which monitoring can be tied.
Your own environment is the next step when full control is needed. A Solana node is deployed in your infrastructure, and you determine the access policy, placement geography, history storage depth, and node update procedure.
This removes dependency on others' restrictions and allows configuring the node for a specific scenario — from streaming transaction writes to mass reading of account state.
A practical rule: with episodic load, a public endpoint is enough; when response time affects business logic, move to dedicated access; with strict requirements for data and independence, move to your own environment.
Typical technical doubts before starting a project
Questions at this stage are almost always the same: can you get by with someone else's access point, what to do with an already working environment, who is responsible for updates after handover. We answer briefly and to the point — the decision should be based on facts, not promises.
Can you get by with shared access to a public endpoint and not run your own node?
For a prototype and low load — yes, a public endpoint covers the task. As soon as peak requests appear, you are standing in someone else's queue: some requests drop off due to limits, response latency jumps, and there is no one to deal with it. Your own node provides predictable throughput and your access rules.
An already deployed environment — does everything need to be rebuilt from scratch?
No. We start with an inventory: what hardware, what configuration, what state the data is in. We keep the working parts and change only what limits load growth.
Migration of the storage scheme and settings proceeds step by step with state verification at each stage — the previous environment remains operational until the new one is confirmed by checks.
How does switching happen without downtime?
The new environment is brought up in parallel and synchronized with the current one. Then we move the traffic in parts: first a small share, and after verifying metrics, the rest.
If latencies or the error rate exceed the threshold, we return requests to the previous environment within minutes. For the user, there is no interruption.
What remains after handover and who is responsible for updates?
We hand over a metrics and alerting dashboard: lag behind the network, response latency, error rate, disk and log usage. We describe updates in a regulation — what and how often, how compatibility is checked, how to roll back.
We go through the first cycle together with your team; after that, you run it yourself or leave it to us.
Where to start: let's discuss the task and come back with an estimate
For the estimate to be substantive, at the start it is enough to describe what task the Solana node solves and how it will be used. Three things matter to us: load profile, current access scheme, and fault-tolerance requirements.
With this set, we already see the architecture of the future environment and do not waste the client's time on general questions.
Separately, we will clarify what is already available and what limitations need to be taken into account:
- Load profile: how many requests per second arrive, what share is data reads, what share is transaction sends, where the peak windows are.
- Current scheme: which services and clients access the network, from which regions, and through what exactly.
- Critical scenarios: what must keep working when a single node or communication channel degrades.
- Availability requirements: allowable downtime, whether a backup node is needed, whether separate entry points for reads and writes are needed.
- Project constraints: access to infrastructure, approval procedure, desired implementation timelines.
- Expected load growth, so that headroom is built in rather than the scheme being reworked a couple of months later.
After that, we come back with an estimate and a work plan: scope of work, implementation timelines, order of stages, and control points at each. The project starts after the plan is approved; at the task discussion stage, there are no obligations.