Answers>Learn about reliability & uptime>Why infrastructure redundancy matters
Warum Redundanz in der Infrastruktur wichtig ist
// Tags
infrastructure redundancy
TL;DR: Redundancy means having backup components at every layer of your infrastructure so that when something fails, a duplicate takes over automatically. In blockchain, redundancy across nodes, regions, cloud providers, and client implementations is what separates production grade systems from fragile ones.
What Redundancy Actually Means
Redundancy is the practice of running more of something than you strictly need during normal operations. The extra capacity isn't wasted. It's insurance.
Think of it like an airplane. Commercial aircraft have redundant engines, redundant hydraulic systems, and redundant navigation instruments. Not because they expect all of them to fail at once, but because any single one might fail at any time. The redundant systems ensure the plane keeps flying even when something breaks.
Infrastructure redundancy follows the same principle. You run extra nodes, in extra regions, on extra cloud providers, not because you need all of them right now, but because you need any subset of them to keep working when the rest go down.
The Layers of Redundancy
Production blockchain infrastructure requires redundancy at multiple levels. Each layer addresses a different type of failure.
Node redundancy is the most basic. Instead of relying on a single node for a given blockchain, you run a pool of them. If one node crashes, falls behind on sync, or starts returning errors, the remaining nodes in the pool handle the traffic. This protects against individual hardware failures, software bugs in a specific node process, or resource exhaustion on a single machine.
Regional redundancy protects against larger failures. If your nodes all run in a single AWS region and that region experiences an outage (which happens more often than most people realize), everything goes down simultaneously. Distributing nodes across multiple geographic regions ensures that a localized event in Virginia doesn't take out your users in Frankfurt or Singapore.
Cloud provider redundancy takes this a step further. If all your infrastructure runs on a single cloud provider and that provider has a platform level incident, regional redundancy alone won't save you. Running across multiple providers (AWS, GCP, bare metal, etc.) means a provider specific outage doesn't become your outage.
Client redundancy is blockchain specific. Most major blockchains have multiple node client implementations. Ethereum has Geth, Erigon, Nethermind, and Besu. Solana has the validator client and Firedancer. If a critical bug appears in one client, nodes running alternative clients continue operating normally. Providers that run a diverse set of clients are more resilient to software level failures.
What Happens Without Redundancy
The consequences of inadequate redundancy are predictable and well documented. In July 2022, the Solana network experienced a significant outage partly related to validator issues. Projects that relied on a single RPC provider in a single region had zero fallback. Their applications went completely dark. Wallet providers couldn't display balances. Trading bots stopped executing. Monitoring dashboards showed nothing.
Compare that to projects with multi provider, multi region setups. They experienced degraded performance but not total failure. Some requests were slower, but the applications stayed online. The difference wasn't luck. It was redundancy.
The Cost of Redundancy vs The Cost of Downtime
A common objection to redundancy is cost. Running nodes in three regions costs roughly three times as much as running them in one. Running across two cloud providers adds another layer of operational complexity and expense.
But consider the cost of downtime. For a DeFi protocol processing $10M in daily volume, even 30 minutes of downtime during peak hours can mean hundreds of thousands in missed trades, liquidation failures, and user trust erosion. For an NFT marketplace during a major drop, a few minutes offline can mean losing an entire cohort of users to a competitor that stayed up.
The math almost always favors redundancy for production applications. The infrastructure cost is fixed and predictable. The cost of downtime is variable and often catastrophic.
What is the difference between redundancy and failover?
Redundancy and failover work together but are not the same thing. Redundancy is having the spare capacity: extra nodes, regions, and providers standing ready. Failover is the mechanism that actually detects a failure and shifts traffic to that spare capacity. Redundancy without failover means you have backups that nobody switches to; failover without redundancy means you have a switch with nothing to switch to. You need both for real resilience.
Aspekt
Redundancy
Failover
What it is
Spare, duplicated capacity
The act of switching to it
Question it answers
Do we have a backup?
How fast do we use it?
Without the other
Backups nobody routes to
A switch with no target
Measured by
Number of independent copies
Detection and switchover time
In short, redundancy is the foundation and failover is the automation on top of it. Together they are the building blocks of high availability.
How does redundancy improve uptime?
Each layer of redundancy removes a different single point of failure, so the more independent layers you stack, the less any one failure can take you fully offline. The table below maps each redundancy layer to the failure it protects against.
Redundancy layer
Protects against
Example failure
Node redundancy
A single node failing
Crash, sync lag, or errors
Regional redundancy
A whole region going down
Cloud region outage
Cloud provider redundancy
A provider-wide incident
Platform-level outage
Client redundancy
A bug in one node client
Consensus bug in one client
Stacking these layers is how providers reach very high uptime targets. It pairs naturally with node reliability practices and an awareness of common blockchain failure modes so each layer targets a real risk.
How much redundancy do you need?
There is no single right answer; the goal is matching redundancy to the cost of being down. A hobby project can tolerate occasional downtime and may need little more than a fallback endpoint, while a DeFi protocol or exchange moving real value needs multi-region and multi-provider coverage with automated failover. Decide by weighing the fixed, predictable cost of redundancy against the variable, potentially catastrophic cost of an outage. This is fundamentally a build versus buy decision, and it only pays off if you can see failures coming, so pair it with strong observability and monitoring of your infrastructure.
Häufig gestellte Fragen
What is infrastructure redundancy?
Infrastructure redundancy is running more components than you strictly need during normal operation so that a backup can take over when something fails. In blockchain, that means duplicate nodes across multiple regions, cloud providers, and client implementations.
Is redundancy the same as a backup?
Not quite. A backup is usually a copy of data you restore after a failure, while redundancy is live spare capacity that keeps serving traffic during a failure with little or no interruption. Redundancy is about staying online, not recovering afterward.
Why run multiple node clients?
Client diversity protects against software bugs. If a critical bug appears in one client implementation, nodes running a different client keep operating normally, so a single buggy release does not take down your entire fleet.
Does redundancy eliminate downtime completely?
No system reaches perfect uptime, but layered redundancy turns most single failures into degraded performance rather than total outages. The aim is to remove single points of failure so that no one event takes everything offline.
Is redundancy worth the extra cost?
For production applications, almost always. Redundancy carries a fixed, predictable cost, while downtime carries a variable cost that can run into hundreds of thousands of dollars in missed trades and lost users during a single peak-hour outage.
How Quicknode Builds Redundancy In
Quicknode runs blockchain infrastructure across 14+ regions on multiple cloud and bare metal providers. Every supported chain runs on a pool of nodes with diverse client implementations where available. The system is designed so that no single node, region, or cloud provider is a single point of failure.
This means developers get production grade redundancy out of the box without having to architect and operate it themselves. For teams needing additional isolation, dedicated clusters offer private infrastructure with custom redundancy configurations.
