Architecting for Active-Active Resiliency in the Cloud
summary
Explains concrete tradeoffs: active‑active reduces downtime but multiplies cost and complexity, while three replicas → 31 seconds downtime quantifies benefit of parallelism. Details data strategies: active-active at service level but not data level to avoid write collisions, or choose global stores like Cloud Spanner, Cosmos DB, Aurora, Cassandra with their replication and collision models. Shows operational patterns that actually work: Kafka/RabbitMQ for async decoupling, Redis/memcached for fallbacks, and Chaos Monkey terminates instances daily to validate failover.
AI-written summary · about
chapters (13)
- 0:00Intro
- 3:49Calculating Availability (Series)
- 4:54Calculating Availability (Paralel)
- 6:06Basic Active Architecture
- 7:34Basic Active-Passive Architecture
- 10:12Basic Active Active Architecture N2
- 13:50Data Replication (Active-Active Data Store)
- 14:40Data Replication (Active-Passive Data Store)
- 15:38Easy Data Replication Databases (Managed)
- 17:05Considering Tenants - What are we failing over?
- 20:02Circuit Breaker Pattern
- 21:03Exponential Backoff Pattern
- 24:29Worker Queues & Streams
related talks
57mResilient Cloud Architecture Design Patterns
49mPatterns for resilient, highly available cloud architectures
51mBuilding for Resiliency and Scale in the Cloud
18mEngineering Resilience at Scale; Lessons from a Distributed Systems Transformation
33mMany Layers of Availability
16mResilient by Design: Architectures for Crisis Response & Recovery
13mEnhancing Cloud Scalability and Fault Tolerance
18mScaling APIs to Billions: Extreme-Scale Reliability