Two service instances each run at 60% CPU behind a load balancer. Is that redundant?
Show the full answer Hide the answer
What is being tested
Whether you size redundancy for the surviving capacity rather than counting instances. This is a common and expensive oversight.
The arithmetic
Total load is 120% of one instance's capacity. Remove one instance and the survivor must serve all of it. It cannot, so it saturates, latency climbs, health checks may start failing, and you now have zero working instances instead of one.
Worse, the failure is often caused by the redundancy: the survivor's collapse is triggered by the first instance's failure, so an event that should have been a partial degradation becomes a total outage.
The rule: N+1 redundancy requires each of the N surviving instances to handle the full load. With two instances, each must be able to run at 100% of total traffic — meaning each sits at or below 50% in normal operation. Three instances gives you 66% each.
There is a corollary worth knowing: higher instance counts are cheaper per unit of redundancy. Going from two instances at 50% to four at 75% provides the same tolerance of one failure with 33% less total capacity, because the load of the lost instance is spread over more survivors.
The larger question the option hints at
Different availability zones is a genuine and necessary improvement, and it does not fix the capacity problem — it addresses correlation, which is the other half of redundancy.
The honest question for any redundant design is: what would take out all copies at once? Common answers, and only the first is what people usually think of:
- A shared dependency. Three instances, one database.
- A bad deployment, which is perfectly correlated across every replica. Instance redundancy provides no protection at all — which is why staged rollout and canaries are a resilience mechanism rather than a delivery convenience.
- A configuration change applied everywhere.
- A shared failure domain: same rack, same power feed, same zone.
- The same bug triggered by the same input.
The full check for a redundant design
- Capacity — can the survivors carry the whole load?
- Correlation — are the failure domains genuinely independent?
- Exercise — has a failure actually been demonstrated, or is the standby assumed to work?
- Detection and switch — will traffic actually move, and how fast?
A design that passes only the first is the most common configuration in production and the one most likely to fail in the way described.