How to make your blockchain data stack reliable
A reliable blockchain data stack keeps your app answering when one provider goes down, falls behind or returns wrong data, whether that provider serves your RPC calls, subgraph queries, webhooks or data API.
This playbook sets out the decisions in the order you’ll make them. Each one links to the use case pages and docs that cover it in detail.
List every data dependency
Write down each RPC endpoint, subgraph, webhook and data API your services call, and which screens or jobs depend on it.
- Use caseWays to improve RPC uptime and reliabilityEach way to build it side by side, with what each one suits best.
- Use caseWays to improve subgraph uptime and reliabilityEach way to build it side by side, with what each one suits best.
- Use caseWays to improve blockchain webhook reliabilityEach way to build it side by side, with what each one suits best.
- Use caseWays to improve blockchain data API reliability and coverageEach way to build it side by side, with what each one suits best.
Decide what has to keep working in an outage
Rank each dependency by what an outage costs, so balances, payments and liquidations get a backup before dashboards do.
Fail over to a backup RPC provider
Keep your provider and retry failed calls on a second endpoint, with your client deciding when to switch and when to come back.
- Use caseImprove RPC uptime with failover to a backup providerYour client sends calls that fail at your main provider to Edge RPC, which responds from several upstream nodes and cross-checks their responses.
- DocsWhy Edge RPCHow Edge RPC fails over between upstream nodes during provider outages, cross-checks their responses and tracks block heights so stale or partial data doesn’t reach you.
Move to an RPC that fails over by itself
Replace your provider with one that spreads calls across several upstream nodes, so there’s no second provider for you to run.
- Use caseImprove RPC uptime by moving to Edge RPCYour app sends all its RPC calls to Edge RPC in place of your current provider.
- DocsWhy Edge RPCHow Edge RPC fails over between upstream nodes during provider outages, cross-checks their responses and tracks block heights so stale or partial data doesn’t reach you.
Take load off your provider
Serve repeated history reads from a cache in front of your provider, so rate limits and outages hit fewer calls.
Run a backup subgraph
Deploy the same subgraph on a second host from its deployment hash, and fail GraphQL queries over when the main one lags or stops syncing.
- Use caseImprove subgraph uptime with failover to a backup subgraphYou deploy the same subgraph a second time on Goldsky from its deployment hash, and your client sends queries that fail or come back stale at the main endpoint to the Goldsky endpoint.
- DocsMigrate subgraphs from The GraphDeploy an existing subgraph on Goldsky from its IPFS deployment hash, with the same GraphQL API your app already queries.
Move the subgraph, or stream its data to your database
Move the subgraph to a host that alerts on stalls, or stream the same events into your own database so no hosted endpoint sits in the read path.
- Use caseImprove subgraph uptime by moving the subgraph to a new hostYou redeploy the subgraph on Goldsky and point your app at it in place of the current host.
- Use caseImprove subgraph uptime by streaming to your own databaseA pipeline backfills the events your subgraph indexes from their start block, decodes them and keeps streaming them into a database you run.
Fix slow syncs before they become downtime
A subgraph that takes days to reindex can’t recover quickly, so cut its sync time before you need to redeploy it.
Retry webhooks and drop repeats
Deliver each event until your endpoint accepts it, and have the endpoint skip any event it has already applied.
- Use caseImprove blockchain webhook reliability by streaming events to your endpointA pipeline watches your address list, matches every transfer in or out of it and posts each one to your endpoint, retrying until your endpoint accepts it.
- DocsTurbo webhook sinkPost pipeline rows to your endpoint as JSON, with retries and at-least-once delivery, so your endpoint has to ignore repeats.
- DocsTurbo Pipelines delivery guaranteesHow Turbo Pipelines delivers every record at least once, why your destination should ignore duplicates, and how reorg corrections reach your database or queue.
Add a second event feed, or a queue
Run a backup feed beside your provider’s webhooks, or publish events to a queue when volume or several consumers outgrow HTTP calls.
- Use caseImprove blockchain webhook reliability with a backup event feedYour provider’s webhooks stay on, and a pipeline posts the same transfers to your endpoint as a second feed.
- Use caseImprove blockchain webhook reliability by streaming events to a queueThe pipeline publishes each matching transfer to a Kafka topic you run instead of posting it to an endpoint, and your services read events at their own pace.
- DocsTurbo Kafka sinkPublish pipeline rows to your Kafka topic as Avro or JSON, at least once, with each row marked as an insert, update or delete.
Back up your data API
Call a second balances and transfers API when yours errors, times out or rate limits you, or move to one that covers the chains you lack.
- Use caseImprove blockchain API availability with failover to a backup APIYour app keeps calling its current blockchain data API and sends a balance or transfer request to Feeds when that API errors, times out or rate limits you, then maps the answer to the same shape your app already uses.
- Use caseImprove blockchain data API reliability by moving to a new APIYour app reads wallet balances, transfers and token metadata and prices from Feeds in place of your current blockchain data API, after you check coverage and compare the two side by side.
- DocsFeeds API overviewThe Feeds endpoints, supported chains and error codes, including the `Retry-After` header on rate limits and busy responses.
Catch wrong data, not just downtime
Cross-check balances and transfers against a second source, because a provider that answers with wrong data looks healthy.
- Use caseCatch wrong balances by cross-checking your blockchain APIYour app calls Feeds for the same wallets’ balances and transfers that your current data API reports, and compares the two answers to find wrong balances and missing transfers.
- Use caseImprove RPC reliability by cross-checking with an APIYour app calls the Feeds API for the same wallets’ balances and transfers that your main provider reports, and compares the two responses.
Get alerted when indexing stalls or lags
Watch each subgraph’s indexing progress and each pipeline’s lag behind the chain, and send alerts to the team that fixes them.
- DocsStalled subgraph detectionHow Goldsky spots a subgraph that has stopped indexing, emails your team, and what to check before you resume or redeploy it.
- DocsTurbo Pipelines health dashboardSpot pipelines falling behind the chain, failed checkpoints and slow sinks across every pipeline in your project.
Test failover before you need it
Switch traffic to each backup on a schedule, so a failover rule that never fires doesn’t fail on the day it matters.
- Use caseImprove RPC uptime and reliability with failoverRun a second data provider behind the incumbent and fail over when it drops data.
- Use caseImprove subgraph uptime and reliability with failoverKeep app screens up when a hosted subgraph lags, stops syncing or goes down, with a backup to fail queries over to.
Turn this plan into a working build
We can help you work through each decision and get the first stage into production.
Robinhood
HyperEVM
Arc
Solana
Ethereum
Polymarket
Base
Tempo
Bitcoin