IS Design #2: Redundancy Should be a Safety Principle

A shelf presents four containers labelled as "backup #1", "backup #2", "backup #3", "backup #4".A shelf presents four containers labelled as "backup #1", "backup #2", "backup #3", "backup #4".
A shelf presents four containers labelled as "backup #1", "backup #2", "backup #3", "backup #4".
Posté par
Cécile G.
Le
17 Feb
.
2026
Copier l’URL de l’article

It only takes one failure from a cloud service provider, an unsuccessful update of your main professional platform, or a network breakdown to put a brutal stop to your business.

On the 4th of March 2025, Google Cloud experienced a major failure which impacted Gmail, Drive, and the other services for a span of several hours. Thousands of companies found themselves unable to carry on with their usual activities.

Those in the lot which had chosen to rely on a single service provider faced a devastating freeze of all their operations.

Redundancy is no spoiled use of resources. It is an insurance against uncertainty, a design principle made to strengthen your information system into a stable architecture.

The Absence of Redundancy comes at a Price

No architecture is foolproof by nature. GAFAM themselves experience failures.

As stated in Google’s Building Secure and Reliable Systems guidelines:

“To address complete failure of system components, system design must incorporate redundancies and distinct failure domains. These tactics can [...] limit the impact of failures and avert complete collapse."

Another example happened in December 2021. AWS suffered a major failure over the US-EAST-1 region. Netflix, Disney+, and Robinhood became inaccessible. How come?

These companies had gathered all their critical assets in a single region, without any automated save system to back them up elsewhere.

For SMB, this scenario is a daily occurrence. One company loses its access to its CRM without any saves.

Another comes to understand the real stakes a lack of its conference call tool on the very day an important presentation to key accounts may be… Well, you get the idea.

Without redundancy, these mishaps turn into crises. With redundancy, they are contained to minor troubles.

The Cost of Redundancy Everybody Tend to Forget

It is too expensive to pay for duplicates.”

Decide for yourself whether you want to play with your finances: the prices of an overextended failure beats that of a redundant infrastructure by a great margin.

A day without access to your CRM is a day’s worth of lost sales. A week without access to the corporate chat is a completely freeze of all communications within the company.

A risk, however slight it appears, is not necessarily so. Simply because its fallout is difficult to perceive does not conveniently make it cheap or minor.

Good news is: you do not need to double your costs by implementing redundancy.

Many SaaS providers now offer "disaster recovery plans" at interesting prices. Setting up an automated backup solution has become an affordable and mundane option in the tech world.

To Practice Redundancy the Smart Way use 3 Key Principles

Practicing redundancy is not duplicating every component in your environment at random.

1) Identify critical components

All tools need different levels of redundancy.

Map out essential services: those whose interruption would put your activity at risk?

This could be your CRM, internal messaging tool, or billing platform for instance.

2) Diversify without fragmenting assets

Plan according to your company’s specific risks and arbitrate accordingly.

If your CRM, messaging tool and cloud storage are all hosted with the same service provider, a general failure would fully paralyse you.

Allocated critical services across several trusted service providers.3) Automate switch off

Redundancy works if it acts fast enough. Using a manual backup system that requires several hours to restore data is not the most protective or efficient way.

Bringing Centralisation and Redundancy Together

Centralising SaaS tools and maintaining redundancy can sound paradoxical.

In practice, these two principles complement each other.

Centralisation helps to simplify daily architecture: less tools, less complexity.

Redundancy protects you from rare but critical incidents: major failures, breaches of security or service provider deficiency.

To summarise, you need to:

  • Centralise daily use tools, while maintaining alternate solutions wherever it is strategically valuable.
  • Split up data saves. Avoid storing data and backups with the same hosting provider.
  • Document switch procedures. Redundancy that nobody knows about, nor understand is silly: it becomes a waste of effort and time-consuming. Teams have to know their way around safety systems in case of need.

Moving from Fragility towards Resiliency

The main difference between a fragile system and a resilient one does not come from the absence of failures. It comes from a system’s capability to keep on functioning despite them.

A system free from redundancy is akin to a chain: one failing link is all it may take for the entire structure to crumble.

Integrating redundancy in a system is acting as a safety net: some threads may break, but the structure will not collapse until holes have been patched.

In a context of ever more numerous the attempts of cyberattacks, coupled with a growing dependency towards digital tools, redundancy should, less than ever before, be viewed as a mere option.

To apply redundancy practically in your own structure, start by identifying the 3 most critical services you have.

To help you do this, ask yourself: if this service were inaccessible tomorrow, how long would it take for the company activities to become paralysed?

If your answer is expressed in a matter of hours, rather than days, you need to invest in redundancy.

Simplicity is a shield from accidental complexity and its opacity.Redundancy is a shield from unpredictability.

Used conjointly, these two principles create the foundations of a truly robust information system.