WebSocket vs HTTP RPC: Subscriptions, Polling and Recovery

Choose by workload

HTTP RPC works well for on-demand reads, historical queries and transaction submission. WebSocket supports a persistent connection and, where the node exposes subscriptions, notifications about new chain activity. Ordinary RPC requests can also travel over WebSocket. The distinction is not "reads versus events," but how the application learns that new data is available.

For a backend that checks progress periodically, HTTP polling may be sufficient. A service reacting to contract events can use subscriptions to avoid waiting for its next poll. Neither transport guarantees fresher data or faster execution: those depend on the node, network path and workload.

A subscription is not a processing checkpoint

On Geth, an eth_subscribe request with ["newHeads"] subscribes to new block headers. Subscriptions belong to their connection and disappear when it closes. They do not provide historical replay. During catch-up, a notification also should not be interpreted as proof that you received every intermediate block. These behaviors are documented in Geth's subscription reference.

Keep a durable record of the last fully processed block and its hash. Treat incoming notifications as a signal to check for work, not as evidence that the application has completed it.

Recover without creating another gap

After a disconnect, reconnect with bounded backoff and establish a new subscription. Reconcile from the durable checkpoint to a chosen eligible block, fetching missing data in bounded ranges. Notifications arriving during recovery should trigger further reconciliation rather than independent, competing recovery jobs.

Commit processing results and checkpoint updates together where possible. Make repeated processing idempotent, and verify block continuity before advancing. Apply the chain's finality and reorganization rules before irreversible actions. Using HTTP for recovery does not make its responses inherently more trustworthy than WebSocket responses. Our dedicated RPC guide for indexers covers the capacity needed for historical catch-up alongside live processing.

Test both paths

A working HTTP endpoint does not demonstrate that subscriptions work. Test connection drops, node restarts, slow consumers and a recovery gap long enough to exercise historical access. Confirm that the backup supports the required subscription types or that the client can fall back to polling. Include subscription recovery in RPC endpoint monitoring and your RPC failover tests.

For dedicated RPC infrastructure, give DTEAM the network, subscription filters, expected event rate and recovery-history requirements. Send us your workload so we can scope a dedicated node with the interfaces and capacity your application needs.