Cell-Based Architecture: o por que estamos sempre tentando mitigar riscos e falhas

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3578101) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } João Antônio Posted on Apr 28 Cell-Based Architecture: o por que estamos sempre tentando mitigar riscos e falhas #backend #systemdesign #architecture #microservices Escalar microserviços horizontalmente resolve capacidade. Mas não resolve isolamento, e essa diferença importa mais do que parece. Cell-Based Architecture é um padrão que ainda é pouco discutido na comunidade, mas que empresas como AWS, Slack já usam há anos para garantir que uma falha nunca afete todos os usuários ao mesmo tempo. A ideia é simples: em vez de escalar instâncias de um mesmo sistema, você replica a stack inteira em unidades independentes chamadas cells, onde cada uma serve um subconjunto da sua base de usuários. O problema com microserviços tradicionais Quando escalamos microserviços horizontalmente, normalmente fazemos isso: O design parece resiliente. Mas na prática, um único ponto de pressão afeta todos os usuários ao mesmo tempo: Um bug em deployment? Todo mundo cai. Um cliente com tráfego absurdo? Degrada a experiência de todos os outros, o famoso noisy neighbor. Uma falha em cascata? Propaga pelo sistema inteiro. Escala horizontal resolve capacidade. Não resolve isolamento. E essa diferença importa muito mais do que parece. O que é uma Cell Uma cell é uma unidade autônoma que contém tudo que precisa para servir um subconjunto de usuários. Aplicação, infraestrutura e banco de dados juntos, completamente isolados das outras cells. Cada cell é funcionalmente idêntica às outras. A diferença é que cada uma serve um pedaço diferente da base de usuários e não sabe que as outras existem. As quatro propriedades que importam ### 1. Blast Radius Containment Se a Cell 2 falha, apenas os usuários entre 1M e 2M são afetados. Os outros continuam operando normalmente. O raio da explosão é previsível e limitado antes mesmo do incidente acontecer. ### 2. Noisy Neighbor Isolation Um cliente corporativo com milhões de requests por dia não consegue degradar a experiência de outros clientes que estão em cells separadas. Cada um vive no seu próprio ambiente. ### 3. Canary deployment natural Você faz deploy na Cell 1, monitora por 30 minutos e só então propaga para as demais. Sem feature flags complexos. O rollback é cirúrgico e afeta só quem precisa. ### 4. Compliance e isolamento por região Precisa garantir que dados de clientes europeus fiquem na Europa? Cells por região resolvem isso de forma estrutural, não como um patch em cima de outro patch. Como o roteamento funciona O Cell Router é o único componente verdadeiramente global. Ele resolve para qual cell cada request deve ir: Request chega | Cell Router consulta: qual cell serve esse tenant_id? | Encaminha para Cell N O mapeamento de tenant_id para cell_id fica em um store leve e altamente disponível. Redis ou DynamoDB funcionam bem aqui ou outro que queira. ## "Mas isso não é só sharding?" Não exatamente, e essa é a confusão mais comum. Sharding é uma estratégia de banco de dados. Você distribui os dados entre múltiplos nós, mas a aplicação continua sendo uma só. Mas nem tudo nesse modelo representa o melhor dos mundos. Existem partes difíceis nessas decisões arquiteturais. Por exemplo, caso seja necessário…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.