# Netflix: Chaos Engineering e Resiliência por Design Uma reconstrução arquitetural de como a Netflix transformou falhas inevitáveis em prática deliberada — da Simian Army ao failover regional automatizado. Este teardown examina as decisões técnicas, os trade-offs reais e o que separa resiliência de verdade de alta disponibilidade cosmética. - URL: https://fernando.moretes.com/studies/netflix-chaos-engineering - Markdown: https://fernando.moretes.com/studies/netflix-chaos-engineering/study.md?lang=pt - Type: Teardown - Company: Netflix - Domain: Resiliência - Date: 2021-06-01 - Tags: chaos-engineering, resiliência, netflix, aws, microservices, failover, simian-army, distributed-systems - Reading time: 7 min --- Em 2011, a Netflix migrou completamente para AWS e, ao fazer isso, aceitou uma premissa incômoda: a infraestrutura vai falhar. A resposta deles não foi tentar evitar falhas — foi construir um sistema que as absorve sem que o usuário perceba. O resultado é uma das arquiteturas de resiliência mais estudadas da indústria, e também uma das mais mal compreendidas. ## Fatos do Caso - **Empresa:** Netflix, Inc. - **Domínio:** Streaming de vídeo, resiliência de plataforma - **Escala (estimada):** ~260 milhões de assinantes, pico >700 Gbps de tráfego de saída - **Migração para AWS:** 2008–2011 (migração completa do datacenter próprio) - **Chaos Monkey — lançamento:** 2011 (open-source em 2012) - **Simian Army:** 2011–2018 (conjunto de ferramentas de injeção de falhas) - **Stack principal:** AWS (EC2, S3, DynamoDB, Route 53), Java/Kotlin (microservices), Zuul (API Gateway), Eureka (service discovery), Hystrix (circuit breaker), Cassandra, Kafka - **Regiões AWS ativas:** 3 regiões ativas simultâneas (us-east-1, us-west-2, eu-west-1 e outras) - **SLO de disponibilidade:** 99,99% de disponibilidade declarada para o serviço de streaming ## O Problema: Alta Disponibilidade Não É Resiliência Antes de 2008, a Netflix operava dois datacenters próprios. Em agosto daquele ano, uma corrupção de banco de dados derrubou o serviço de DVD por três dias — um incidente que expôs a fragilidade de uma arquitetura monolítica onde um único ponto de falha podia paralisar tudo. A decisão de migrar para AWS não foi apenas operacional; foi uma aposta arquitetural de que a nuvem, com sua elasticidade e redundância geográfica, permitiria construir algo qualitativamente diferente. O problema real, porém, não era a infraestrutura. Era a cultura e a engenharia ao redor dela. Sistemas distribuídos em nuvem introduzem uma classe de falhas que datacenters tradicionais raramente experimentam em produção: instâncias que somem silenciosamente, latências que explodem de forma assimétrica, partições de rede que isolam zonas inteiras. A resposta convencional é tentar prevenir essas falhas com redundância passiva — múltiplas AZs, replicação síncrona, failover automático configurado mas nunca testado. A Netflix rejeitou essa abordagem. A premissa central que guia toda a arquitetura de resiliência deles é: **se você não testa falhas em produção, você não sabe se seu sistema sobrevive a elas**. Redundância não testada é ilusão de redundância. Um failover que nunca foi exercitado em condições reais vai falhar no pior momento possível — quando a carga está no pico, quando a equipe está dormindo, quando o incidente já está em andamento. Essa premissa não é filosófica; ela é operacional. E foi ela que gerou a Simian Army. ## Arquitetura de Resiliência Reconstruída Fluxo de uma requisição de streaming atravessando múltiplas camadas de resiliência, com os pontos de injeção de falha da Simian Army e os mecanismos de degradação graciosa. ### 👤 Client - Client (TV/Mobile/Web) (user) ### 🌐 Edge / CDN - Netflix CDN (Open Connect) (edge) - Route 53 DNS Failover (network) ### 🔀 API Gateway Layer - Zuul API Gateway (frontend) - Eureka Service Discovery (network) ### ⚙️ Microservices (us-east-1 — Primary) - Auth Service (stateless) (compute) - Catalog Service (read-heavy) (compute) - Recommendation Service (compute) - Hystrix Circuit Breaker (security) ### 💾 Data Layer - Cassandra (multi-region) (data) - DynamoDB (session/state) (data) - S3 (assets/fallback) (storage) - Kafka (event stream) (messaging) ### 🐒 Simian Army (Fault Injection) - Chaos Monkey Kills instances (ci) - Chaos Kong Kills AZ/Region (ci) - Latency Monkey Injects delay (ci) - Conformity Monkey Best practices (ci) ### 🌍 Failover Region (us-west-2) - Zuul (standby-active) (frontend) - Microservices (active replica) (compute) - Cassandra (replica) (data) ### Fluxos - client -> cdn: vídeo (bytes) - client -> r53: DNS lookup - r53 -> zuul: roteia para região primária - zuul -> eureka: resolve serviço - zuul -> hystrix: toda chamada passa pelo CB - hystrix -> auth: autenticação - hystrix -> catalog: catálogo - hystrix -> reco: recomendações - catalog -> cassandra: leitura - auth -> dynamo: sessão - reco -> s3: fallback estático - catalog -> kafka: eventos de uso - chaos_monkey -> auth: termina instância - chaos_monkey -> catalog: termina instância - chaos_kong -> zuul: remove região inteira - latency_monkey -> reco: injeta 2-5s de latência - r53 -> zuul_dr: failover DNS automático - zuul_dr -> services_dr: tráfego redirecionado - services_dr -> cassandra_dr: dados replicados - cassandra -> cassandra_dr: replicação async ## Como o Sistema Funciona: Camadas de Resiliência A arquitetura de resiliência da Netflix não é um produto único — é uma composição de mecanismos independentes que se reforçam. Entender cada camada separadamente é essencial para entender por que o conjunto funciona. **Camada 1 — Degradação Graciosa com Hystrix.** Todo serviço que faz chamadas a dependências externas é envolvido por um circuit breaker Hystrix. Quando uma dependência começa a falhar ou a exceder timeouts configurados, o circuito abre e a chamada retorna imediatamente um valor de fallback — geralmente dados em cache, uma resposta estática ou uma versão degradada da feature. O exemplo canônico é o serviço de recomendações: se ele falha, o usuário recebe uma lista de filmes populares pré-computada em vez de recomendações personalizadas. A experiência é pior, mas o serviço continua funcionando. Esse padrão — *fail fast, fallback gracefully* — é aplicado sistematicamente em centenas de microservices. **Camada 2 — Service Discovery Dinâmico com Eureka.** O Eureka é o registro de serviços interno da Netflix. Cada instância se registra ao iniciar e envia heartbeats periódicos. Quando uma instância morre — seja por falha real ou por ação do Chaos Monkey — ela é removida do registro em segundos. O Zuul, o API Gateway, consulta o Eureka para rotear requisições apenas para instâncias saudáveis. Não há DNS TTL longo para aguardar; a convergência é rápida. Isso significa que a morte de uma instância individual é absorvida pela camada de roteamento sem intervenção humana. **Camada 3 — Failover Regional com Chaos Kong.** O nível mais alto de resiliência é o failover regional. A Netflix opera em múltiplas regiões AWS simultaneamente — não em modo ativo-passivo, mas ativo-ativo com capacidade de absorver o tráfego de uma região inteira. O Chaos Kong simula a perda completa de uma região: ele desvia todo o tráfego de, digamos, us-east-1 para us-west-2 via Route 53, e a equipe observa se o sistema aguenta. Esse exercício é feito periodicamente em produção. A Cassandra, o banco de dados principal para dados de catálogo e perfil, opera com replicação multi-região configurada para consistência eventual — uma escolha deliberada que prioriza disponibilidade sobre consistência forte (teorema CAP, partição AP). **Camada 4 — A Simian Army como Cultura de Engenharia.** A Simian Army não é apenas um conjunto de ferramentas; é a institucionalização de uma cultura. O Chaos Monkey roda durante o horário comercial (não à meia-noite) de forma deliberada — se vai causar um problema, é melhor que aconteça quando a equipe está acordada e pode responder. O Conformity Monkey verifica se as instâncias seguem as melhores práticas configuradas. O Security Monkey audita configurações de segurança. O Doctor Monkey faz health checks. Cada macaco ataca uma dimensão diferente da resiliência, e o conjunto cria pressão contínua para que os times construam serviços que sobrevivem a falhas em vez de depender de que as falhas não aconteçam. ## Os Princípios de Chaos Engineering: O Que a Netflix Formalizou Em 2014, a Netflix publicou o documento *Principles of Chaos Engineering* — uma tentativa de formalizar o que estava sendo praticado empiricamente. Os princípios são cinco, e cada um tem implicações arquiteturais diretas que vale examinar com cuidado. **1. Construa uma hipótese sobre o comportamento em estado estável.** Antes de injetar qualquer falha, você precisa definir o que é normal. Para a Netflix, isso significa métricas de negócio — *stream starts per second* (SPS) é a métrica primária, não CPU ou latência. Se o SPS cai, algo está errado. Essa escolha de métrica é arquiteturalmente importante: ela força a instrumentação a ser orientada ao resultado de negócio, não ao estado técnico interno. **2. Varie eventos do mundo real.** As falhas injetadas devem refletir o que realmente acontece: instâncias que morrem, discos que falham, latências de rede que aumentam, dependências externas que ficam lentas. Não é sobre criar cenários artificiais — é sobre reproduzir em condições controladas o que a produção já experimenta de forma não controlada. **3. Execute experimentos em produção.** Esse é o princípio mais controverso e o mais importante. Ambientes de staging não replicam a carga real, os padrões de tráfego reais, os dados reais. Um bug que só aparece com 10 milhões de requisições simultâneas não vai aparecer no staging. A Netflix aceita o risco de degradação em produção como o custo de ter confiança real na resiliência. **4. Automatize experimentos para rodar continuamente.** Resiliência não é um estado que você atinge uma vez; é uma propriedade que precisa ser mantida. Cada deploy novo pode introduzir uma regressão de resiliência. Chaos Monkey rodando continuamente garante que o sistema seja testado sob condições de falha após cada mudança. **5. Minimize o raio de explosão.** Experimentos começam pequenos — uma instância, uma AZ, um percentual do tráfego. O raio de explosão é expandido gradualmente à medida que a confiança aumenta. Isso é o que permite rodar em produção sem causar incidentes maiores sistematicamente. O que a Netflix fez foi transformar esses princípios em infraestrutura executável. A distância entre o princípio e a implementação é onde a maioria das organizações falha — elas adotam o vocabulário do chaos engineering sem construir os mecanismos de fallback que tornam os experimentos seguros de executar. ## Trade-offs Arquiteturais Centrais ### Consistência Eventual (AP) vs. Consistência Forte (CP) **Pros** - Disponibilidade máxima mesmo durante partições de rede - Latência de leitura previsível sem coordenação entre réplicas - Failover regional sem bloqueio de escrita **Cons** - Usuário pode ver dados ligeiramente desatualizados (perfil, histórico) - Conflitos de escrita em cenários de split-brain precisam de resolução **Verdict:** Correto para o domínio: streaming tolera staleness de segundos; indisponibilidade não é tolerada. ### Ativo-Ativo Multi-Região vs. Ativo-Passivo **Pros** - Failover sem cold-start: a região de destino já está quente - Tráfego real valida continuamente a capacidade da região secundária **Cons** - Custo operacional ~2x: toda a capacidade precisa existir em múltiplas regiões - Complexidade de sincronização de dados entre regiões **Verdict:** Justificado pelo SLO de 99,99%: o custo do downtime supera o custo da redundância ativa. ### Chaos em Produção vs. Chaos em Staging **Pros** - Testa o sistema real com carga real e dados reais - Detecta regressões de resiliência introduzidas por novos deploys **Cons** - Risco de degradação de experiência para usuários reais - Requer maturidade operacional alta: fallbacks precisam existir antes dos experimentos **Verdict:** Correto para Netflix; perigoso sem os mecanismos de degradação graciosa já implementados. ### Circuit Breaker Automático vs. Timeout Simples **Pros** - Previne cascata de falhas: um serviço lento não derruba o upstream - Recuperação automática sem intervenção humana **Cons** - Configuração de thresholds é difícil: muito sensível gera falsos positivos - Fallback precisa ser implementado explicitamente por cada serviço **Verdict:** Indispensável em arquitetura de microservices com centenas de dependências. ## Leitura Well-Architected - **security**: **Adequado, mas não o foco principal desta arquitetura.** O Security Monkey (parte da Simian Army) audita configurações de segurança continuamente. A arquitetura de microservices com Zuul como ponto de entrada centralizado facilita a aplicação de políticas de autenticação e autorização. O ponto cego histórico foi a superfície de ataque ampla de uma arquitetura com centenas de microservices — cada um potencialmente com sua própria configuração de segurança. - **reliability**: **Excelente, com nuances.** A Netflix é o caso de referência para o pilar de confiabilidade. Múltiplas AZs, múltiplas regiões ativas, circuit breakers, health checks automatizados, service discovery dinâmico e chaos engineering contínuo. O único ponto de atenção é que a consistência eventual introduz janelas de inconsistência que, em domínios financeiros, seriam inaceitáveis — mas para streaming, é a escolha correta. - **sustainability**: **Não endereçado explicitamente na literatura pública.** O uso de Spot Instances para workloads de encoding reduz o desperdício de capacidade. A CDN própria (Open Connect) instalada em ISPs reduz a distância física dos bytes, o que tem benefício energético indireto. Mas a redundância ativa em múltiplas regiões implica consumo energético significativamente maior do que uma arquitetura ativo-passivo. > **O Que Eu Faria Diferente — e o Que Eu Levaria Para Qualquer Projeto:** A arquitetura da Netflix é genuinamente impressionante, mas há três coisas que eu questionaria ou ajustaria, e uma lição que aplico em todo projeto de resiliência. **O que eu questionaria:** O Hystrix foi descontinuado em 2018, e a Netflix migrou para o Resilience4j e soluções baseadas em service mesh (Envoy/Istio). A lição aqui é que circuit breakers na camada de aplicação têm um problema fundamental: eles são invisíveis para a infraestrutura. Um service mesh resolve isso movendo a lógica de resiliência para o sidecar, tornando-a observável e configurável sem mudança de código. Se eu estivesse projetando hoje, começaria com Envoy como sidecar e não com Hystrix na aplicação. **O que eu ajustaria na Simian Army:** A Simian Army foi descontinuada como projeto unificado. As ferramentas foram substituídas por soluções mais modernas e integradas ao ecossistema AWS (AWS Fault Injection Simulator, por exemplo). O problema da Simian Army original era que cada macaco era um serviço independente com seu próprio ciclo de vida — difícil de manter, difícil de coordenar. Uma abordagem moderna seria usar FIS com hipóteses definidas como código (IaC), integradas ao pipeline de CI/CD, com rollback automático se a métrica de estado estável degradar além de um threshold. **O que eu faria diferente em consistência:** Para dados de perfil e preferências do usuário, eu exploraria CRDTs (Conflict-free Replicated Data Types) em vez de resolução de conflito ad-hoc. CRDTs garantem convergência eventual sem conflitos — uma escolha mais elegante que 'last write wins' para dados de usuário. **A liç ## Veredicto A Netflix construiu a arquitetura de resiliência mais influente da última década — não porque seja perfeita, mas porque é honesta. Ela parte de uma premissa que a maioria das organizações evita admitir: falhas são inevitáveis, e a única forma de saber se você sobrevive a elas é testá-las deliberadamente. O resultado é um sistema onde cada camada — do circuit breaker individual ao failover regional — existe porque foi validada sob condições reais, não porque parecia boa no diagrama. O que torna essa arquitetura difícil de replicar não é a tecnologia — Hystrix, Eureka, Cassandra são open-source. O que é difícil de replicar é a cultura que aceita rodar o Chaos Monkey em produção durante o horário comercial, que mede resiliência em SPS e não em uptime de instância, que trata cada falha como um experimento e não como um incidente de vergonha. Essa cultura é o produto arquitetural mais valioso que a Netflix construiu. Para times que querem aprender com esse caso: não comece pelo Chaos Monkey. Comece pelos fallbacks. Implemente degradação graciosa em cada serviço crítico, defina sua métrica de estado estável, e só então comece a injetar falhas. Chaos engineering sem fallbacks é apenas d ## Referências - [Netflix Tech Blog](https://netflixtechblog.com/) - [Principles of Chaos Engineering](https://principlesofchaos.org/) - [Netflix Tech Blog: The Netflix Simian Army (2011)](https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116) - [Netflix Tech Blog: Chaos Engineering Upgraded (2018)](https://netflixtechblog.com/chaos-engineering-upgraded-878d341f15fa) - [Netflix Tech Blog: Active-Active for Multi-Regional Resiliency](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b) - [Netflix Tech Blog: Hystrix — Latency and Fault Tolerance](https://netflixtechblog.com/introducing-hystrix-for-resilience-engineering-13531c1ab362) - [AWS Fault Injection Simulator (FIS) Documentation](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) - [Netflix Tech Blog: Eureka — Service Discovery at Netflix](https://netflixtechblog.com/eureka-the-netflix-service-discovery-framework-the-heart-of-mid-tier-load-balancing-6a23c6a3dbb6) ## Fontes do caso - [Netflix Tech Blog](https://netflixtechblog.com/) - [Principles of Chaos Engineering](https://principlesofchaos.org/)