# When Redundancy Actually Helps

DevFeed: [When Redundancy Actually Helps](<https://devfeed.tech/articles/when-redundancy-actually-helps-12488.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2019/06/20/redundancy.html>)

Author: Marc Brooker

Published: 2019-06-20T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Availability](<https://devfeed.tech/topics/availability.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [cost](<https://devfeed.tech/tags/cost.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [performance](<https://devfeed.tech/tags/performance.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [replication](<https://devfeed.tech/tags/replication.md>), [systems](<https://devfeed.tech/tags/systems.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

This article examines when redundancy improves system availability. It argues that redundancy can increase risk if it adds too much complexity, and outlines requirements including degraded-mode operation, reliable health detection, sufficient failover capacity, and a return to fully redundant operation. It also discusses active-passive database failover, capacity planning, and continuous testing.

## Source excerpt

When Redundancy Actually Helps Redundancy can harm more than it helps. Just after I joined the EBS team at AWS in 2011, the service suffered a major disruption lasting more than two days to full recovery. Recently, on Twitter, Andrew Certain said: We were super dependent on having a highly available network to make the replication work, so having two NICs and a second network fabric seemed to be a way to improve availability. But the lesson of this event is that only some forms of redundancy improve availability. I've been thinking about the second part of that a lot recently, as my team starts building a new replicated system. When does redundancy actually help availability? I've been breaking that down into four rules: The complexity added by introducing redundancy mustn't cost more availability than it adds. The system must be able to run in degraded mode. The system must reliably detect which of the redundant components are healthy and which are unhealthy. The system must be able to return to fully redundant mode. This might seem like obvious, even tautological, but each serves as the trigger of deeper thinking and conversation. Don't add more risk than you take away Andrew (or Kerry Lee, I'm not sure which) introduced this to the EBS team as don't be weird. So I think it reinforces two lessons: 1/ Don't be weird 2/ Modality is bad -- Andrew Certain (@tacertain) July 20, 2019 This isn't a comment on people (who are more than welcome to be weird), but on systems. Weirdness and complexity add risk, both risk that we don't understand the system that we're building, and risk that we don't understand the system that we are operating. When adding redundancy to a system, it's easy to fall into the mistake of adding too much complexity, and underestimating the ways in which that complexity adds risk. You must be able to run in degraded mode Once you've failed over to the redundant component, are you sure it's going to be able to take the load? Even in one of the simplest