Conceitos
Arquitetura celular e raio de impacto
Intuição
Um navio é dividido em compartimentos estanques: se o casco é rompido, a água fica contida em uma seção e o navio segue flutuando. Um serviço pode ser dividido do mesmo jeito, em várias cópias completas e independentes, cada uma atendendo só uma parte dos clientes. Assim, quando uma cópia falha, só os clientes daquela cópia sentem o problema.
Como funciona
Na arquitetura celular, o serviço é dividido em células, e cada célula é uma instância completa da carga de trabalho que, idealmente, não compartilha estado nem faz chamadas a outras células. Um roteador de células, a camada mais fina possível, apresenta um único endpoint aos clientes e encaminha cada requisição à célula certa a partir de uma chave de partição, como o ID do cliente, alinhada ao grão do serviço. Um plano de controle provisiona e remove células e migra clientes entre elas, enquanto o plano de dados (roteador e células) executa a função principal do serviço; pela estabilidade estática, o plano de dados segue funcionando mesmo quando o plano de controle está prejudicado. O escopo de impacto é limitado pelo número de células: com 10 células, uma falha em uma delas deixa 90% das requisições sem impacto, e com 100 células cada uma representa 1% do serviço. O shuffle sharding refina a atribuição: em vez de um shard fixo, cada cliente recebe uma combinação de workers, e com oito workers e combinações de dois há 28 shuffle shards possíveis; com centenas de clientes ou mais, cada um em um shuffle shard, o escopo de um problema é de 1/28, contra 1/4 no sharding comum com quatro shards. Nesse arranjo, o problema de um cliente atinge no máximo um worker de qualquer outro shuffle shard (com shards maiores, pode-se garantir um limite de sobreposição, como no máximo dois servidores em comum entre shards de quatro), e o serviço aos demais fica garantido se os solicitantes toleram falhas e contornam o problema, por exemplo com retentativas. Na implantação, publica-se em ondas, célula a célula ou em conjuntos, com a primeira célula como canary e rollback ao primeiro sinal de falha. Há custos: mais complexidade, mais infraestrutura e um roteador que é ponto único de falha e também deve ser construído de forma celular; além disso, células não foram pensadas como domínios de failover nem para mitigar falhas de dependência.
Na prática
Faz sentido para cargas que exigem resiliência extrema e aceitam o custo extra de complexidade e infraestrutura, desde que se saiba qual chave (cliente, recurso) delimita quem deve ser isolado de quem. No Route 53, segundo o artigo sobre shuffle sharding, cada domínio recebe um shuffle shard de quatro entre 2048 servidores virtuais, nenhum domínio compartilha mais de dois deles com outro, e um DDoS contra um domínio não é percebido pelos demais. A mesma lógica vale nos deploys: publicar célula a célula, com a primeira como canary e rollback ao primeiro sinal de falha, mantém um erro de versão restrito a poucos clientes.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.