A priorização de carga e o load shedding tornaram-se pilares fundamentais da infraestrutura da Netflix para garantir que o serviço permaneça online mesmo diante de picos de tráfego inesperados.
Em um ambiente onde o lançamento de uma nova série ou um evento ao vivo pode atrair milhões de usuários simultâneos, a capacidade de descartar requisições menos críticas para preservar as essenciais é o que separa uma experiência fluida de um colapso total.
O desafio dos picos de tráfego na infraestrutura
O load shedding na Netflix funciona priorizando requisições iniciadas pelo usuário sobre tráfego de fundo, utilizando o Envoy sidecar proxy para descartar excessos antes que eles causem falhas em cascata ou consumo total de memória.
Gerenciar o tráfego em uma escala global como a da Netflix exige mais do que apenas escalonamento automático. Enquanto o autoscaling reativo pode demorar minutos para provisionar novas instâncias, picos abruptos causados por “efeitos de manada” podem derrubar serviços em segundos. A solução encontrada pelos engenheiros Anirudh Mendiratta e Benjamin Fedorka envolveu a implementação de mecanismos que permitem que o sistema degrade graciosamente em vez de falhar completamente.
Ao contrário do rate limiting, que impõe limites fixos por usuário para fins de monetização ou controle, o load shedding foca na capacidade total do cluster. Quando o volume de requisições excede a capacidade provisionada, o sistema decide, em tempo real, quais requisições podem ser descartadas para manter a latência aceitável para o tráfego crítico, como o início de uma reprodução de vídeo.
Implementação de priorização de carga
A arquitetura atual da Netflix integra a lógica de load shedding diretamente no Envoy sidecar proxy. Essa abordagem permite uma camada de inteligência próxima ao serviço, decidindo o destino de cada pacote com base em prioridade sem sobrecarregar a lógica da aplicação.
1. Priorização de requisições iniciadas pelo usuário
O sistema categoriza requisições entre críticas e não críticas. Requisições que disparam a reprodução de um título são tratadas com prioridade máxima. Caso o cluster atinja seu limite de processamento, o proxy descarta automaticamente requisições de segundo plano, como carregamento de metadados secundários ou telemetria não essencial, garantindo que o usuário consiga assistir seu conteúdo.
2. Mitigação de falhas em cascata
Sem o load shedding, um aumento na latência de um único serviço pode causar o acúmulo de threads, levando ao esgotamento de memória e à falha total do nó. Ao descartar requisições em excesso, a Netflix protege a integridade do restante do sistema, evitando que instâncias saudáveis recebam a carga de instâncias que falharam, um problema clássico conhecido como cascading failure.
O uso de attempt budgets (orçamentos de tentativa) nas requisições do lado do cliente evita que o fenômeno de retry storms sature a rede, garantindo que o sistema tenha espaço para se recuperar de picos temporários de carga sem intervenção manual.
O futuro da resiliência em sistemas distribuídos
Para o desenvolvedor brasileiro atuando com arquiteturas de microsserviços ou sistemas de alta disponibilidade, o caso da Netflix serve como uma aula de engenharia de resiliência. A chave não está em tentar escalar infinitamente para cobrir todos os cenários possíveis, mas sim em desenhar sistemas que saibam o que sacrificar quando os recursos se tornam escassos.
A automação de testes de caos, ou chaos engineering, é o próximo passo natural para validar essas políticas de priorização continuamente.
Perguntas frequentes
Como o load shedding difere do rate limiting?
O load shedding foca na gestão da capacidade total do servidor, descartando requisições menos importantes quando o sistema está saturado. Já o rate limiting aplica limites de taxa por usuário, geralmente por motivos de segurança ou limites contratuais, sem necessariamente considerar o estado atual de carga do cluster.
Por que o autoscaling não resolve todos os picos?
O autoscaling reativo depende do tempo de inicialização de instâncias, que pode levar minutos, tempo suficiente para uma falha ocorrer durante um pico súbito. Além disso, em momentos de carga extrema global, o provedor de nuvem pode enfrentar restrições de capacidade, tornando impossível escalar além de um certo ponto.
O que são retry storms em sistemas distribuídos?
São tempestades de novas tentativas automáticas realizadas por clientes quando um serviço começa a ficar lento. Se não controladas, essas tentativas repetidas sobrecarregam ainda mais o serviço já degradado, transformando um pequeno atraso em uma interrupção completa. O uso de attempt budgets e backoff exponencial são as defesas padrão contra esse comportamento.
