# Redundant against what?

DevFeed: [Redundant against what?](<https://devfeed.tech/articles/redundant-against-what-12506.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2021/04/14/redundancy.html>)

Author: Marc Brooker

Published: 2021-04-14T00: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: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [availability](<https://devfeed.tech/tags/availability.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [kafka](<https://devfeed.tech/tags/kafka.md>)

## AI overview

The article explains that redundancy is the fundamental reason distributed systems can achieve higher availability than single-box systems. It examines infrastructure, software, and logical failures, emphasizing that redundancy can introduce complexity and must be designed against specific failure modes. An event-log example illustrates how replicated systems handle host failures but may still be vulnerable to poison-pill events.

## Source excerpt

Redundant against what? Threat modeling thinking to distributed systems. There's basically one fundamental reason that distributed systems can achieve better availability than single-box systems: redundancy. The software, state, and other things needed to run a system are present in multiple places. When one of those places fails, the others can take over. This applies to replicated databases, load-balanced stateless systems, serverless systems, and almost all other common distributed patterns. One problem with redundancy is that it adds complexity, which may reduce availability. Another problem, and the one that people tend to miss the most, is that redundancy isn't one thing. Like security, redundancy is a single word that we mean that our architectures and systems are resistant to different kinds of failures. That can mean infrastructure failures, where redundancy could mean multiple machines, multiple racks, multiple datacenters or even multiple continents. It can mean software failures, where common techniques like canary deployments help systems to be redundant when one software version failures. I can also mean logical failures, where we recognize that state can affect the performance or availability of our system, and we try ensure that the same state doesn't go to every host. Sometimes that state is configuration, sometimes it's stored data or requests and responses. An Example Unfortunately, when we talk about system designs, we tend to forget these multiple definitions of redundancy and instead just focus on infrastructure. To show why this matters, let's explore an example. Event logs are rightfully a popular way to build large-scale systems. In these kinds of systems there's an ordered log which all changes (writes) flows through, and the changes are then applied to some systems that hang off the log. That could be read copies of the data, workflow systems taking action on the changes, and so on. In the simple version of this pattern one thing is true: