Redundancy
Redundancy
Redundancy duplicates critical components to survive failures.
Types of Redundancy
1. Hardware Redundancy:
- Multiple servers
- RAID storage
- Redundant power supplies
2. Software Redundancy:
- Multiple instances
- Replica sets
- Load balancers
3. Data Redundancy:
- Replication
- Backups
- Geographic distribution
4. Network Redundancy:
- Multiple paths
- Failover routes
- Redundant NICs
Replication Strategies
1. Master-Slave:
[Master] → [Slave 1]
→ [Slave 2]
Writes to master, reads from slaves
2. Multi-Master:
[Master A] ←→ [Master B]
Both accept writes, sync
3. Peer-to-Peer:
[Node A] ←→ [Node B] ←→ [Node C]
All nodes equal
Replication Factor
Replication Factor = Number of copies
RF=1: No redundancy
RF=2: Tolerates 1 failure
RF=3: Tolerates 2 failures
RF=2f+1: Tolerates f failures
Configuration
replication:
factor: 3
strategy: rack-aware
consistency: quorum
failover: automatic
Failover
Failover
Failover automatically switches to a redundant component when primary fails.
Failover Types
1. Active-Passive:
[Active] → [Passive]
Primary fails → Secondary activates
2. Active-Active:
[Active] ←→ [Active]
Both handle traffic
One fails → Other takes full load
3. N+1:
[Active 1] [Active 2] [Active 3] → [Standby]
Any fails → Standby takes over
4. N+N:
[Active 1] [Active 2] [Active 3]
[Active 4] [Active 5] [Active 6]
Full redundancy
Failover Process
1. Detection:
- Heartbeat failure
- Health check failure
- Error rate spike
2. Decision:
- Automatic or manual
- Consensus for split-brain
3. Switchover:
- Update DNS/registry
- Redirect traffic
- Sync state
4. Recovery:
- Fix failed node
- Sync data
- Rejoin cluster
Implementation
class FailoverManager:
def __init__(self, primary, secondary):
self.primary = primary
self.secondary = secondary
self.active = primary
self.health_checker = HealthChecker()
def check_health(self):
if not self.health_checker.is_healthy(self.active):
self.failover()
def failover(self):
if self.active == self.primary:
self.active = self.secondary
else:
self.active = self.primary
self.sync_state()
self.notify_clients()
def sync_state(self):
# Sync state from old to new primary
pass
Split-Brain Prevention
Problem: Two nodes both think they're primary
Solutions:
1. Fencing: Kill old primary
2. STONITH: Shoot The Other Node In The Head
3. Quorum: Require majority for leadership
4. Watchdog: Hardware timeout
Graceful Degradation
Graceful Degradation
What is Graceful Degradation?
Full Functionality → Reduced Functionality → Core Only
When components fail:
- Disable non-essential features
- Maintain core functionality
- Inform users of limitations
Degradation Strategies
1. Feature Toggles:
Disable features when dependencies fail
2. Fallback Responses:
Return cached/default data
3. Reduced Quality:
Lower resolution, fewer results
4. Queue for Later:
Accept request, process when recovered
Implementation
class GracefulDegradation:
def __init__(self):
self.features = {
'recommendations': True,
'reviews': True,
'analytics': True
}
def get_product(self, product_id):
product = self.db.get_product(product_id)
# Degrade gracefully
if self.features['recommendations']:
product['recommendations'] = self.get_recommendations(product_id)
else:
product['recommendations'] = []
if self.features['reviews']:
product['reviews'] = self.get_reviews(product_id)
else:
product['reviews'] = []
return product
def disable_feature(self, feature):
self.features[feature] = False
self.notify_degradation(feature)
Degradation Levels
| Level | Description | User Impact |
|---|---|---|
| L0 | Full functionality | None |
| L1 | Minor features disabled | Minimal |
| L2 | Major features disabled | Moderate |
| L3 | Core only | Significant |
| L4 | Error page | Complete |
Monitoring
def monitor_degradation(service):
for feature, enabled in service.features.items():
if not enabled:
alert(f'{feature} is degraded')
metrics.gauge('degradation.level', get_degradation_level())
Practice Problems
Design a scalable Fault Tolerance system. Cover high-level architecture, data model, and API design.
Solution
// Complete system design:
// - Functional + Non-functional requirements
// - Capacity estimation
// - Data model (SQL/NoSQL choice)
// - API endpoints
// - Component architecture
// - Scaling strategy
// - Monitoring & reliabilityHow would you scale Fault Tolerance to handle 10x the current load? Identify bottlenecks and solutions.
Solution
// Scaling approach:
// 1. Load balancing
// 2. Database sharding/replication
// 3. Cache layer (Redis)
// 4. CDN for static assets
// 5. Async processing (queues)
// 6. Microservices decompositionAnalyze potential failure modes for Fault Tolerance and design mitigation strategies.
Solution
// Failure mitigation:
// 1. Redundancy (multi-AZ)
// 2. Circuit breakers
// 3. Retry with backoff
// 4. Dead letter queues
// 5. Health checks
// 6. Graceful degradationQuiz
1. What is redundancy in fault tolerance?
2. What is split-brain in failover?
3. What is graceful degradation?
4. What is replication factor 3?
5. How to prevent split-brain?
Flashcards
Question
What is redundancy?
Click to reveal answer
Answer
Duplicating critical components (hardware, software, data, network) to survive failures
Question
What is split-brain?
Click to reveal answer
Answer
When two nodes both think they're primary, causing data inconsistency - prevented by quorum/STONITH
Question
What is graceful degradation?
Click to reveal answer
Answer
Maintaining core functionality while disabling non-essential features during failures
Question
Replication factor 3 tolerates?
Click to reveal answer
Answer
2 node failures - 3 copies means 2 can fail while maintaining availability
Question
Active-Passive vs Active-Active failover?
Click to reveal answer
Answer
Active-Passive: standby activates on failure. Active-Active: both handle traffic, one takes full load on failure.
Revision Notes
Key Takeaways
- 1.Redundancy duplicates critical components for fault tolerance
- 2.Failover automatically switches to redundant components
- 3.Split-brain prevented by quorum or STONITH
- 4.Graceful degradation maintains core functionality
- 5.Replication factor determines failure tolerance
Interview Tips
- •Explain redundancy types and trade-offs
- •Discuss failover mechanisms and split-brain
- •Give examples of graceful degradation
- •Know replication factor calculations
Cheat Sheet
Cheat Sheet: Fault Tolerance
Redundancy
- Hardware: Multiple servers
- Software: Replica sets
- Data: Replication
- Network: Multiple paths
Failover
- Active-Passive
- Active-Active
- N+1 standby
- Split-brain prevention
Graceful Degradation
- Disable non-essential features
- Maintain core functionality
- Fallback responses
- Inform users
Replication
- RF=3 tolerates 2 failures
- Quorum for consistency