Skip to content
intermediatePhase 48 · Distributed Systems

Fault Tolerance

Design systems that continue operating despite component failures.

45m
0 problems
Topic Progress0%

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

0/3solved
Design Fault Tolerance System

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 & reliability
Fault Tolerance Scaling

How 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 decomposition
Fault Tolerance Failure Modes

Analyze 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 degradation

Quiz

1. What is redundancy in fault tolerance?

Question 1 options

2. What is split-brain in failover?

Question 2 options

3. What is graceful degradation?

Question 3 options

4. What is replication factor 3?

Question 4 options

5. How to prevent split-brain?

Question 5 options

Flashcards

Question

What is redundancy?

Answer

Duplicating critical components (hardware, software, data, network) to survive failures

Question

What is split-brain?

Answer

When two nodes both think they're primary, causing data inconsistency - prevented by quorum/STONITH

Question

What is graceful degradation?

Answer

Maintaining core functionality while disabling non-essential features during failures

Question

Replication factor 3 tolerates?

Answer

2 node failures - 3 copies means 2 can fail while maintaining availability

Question

Active-Passive vs Active-Active failover?

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