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

Source: Dev.to

Visão Geral

Cell‑Based Architecture é um padrão ainda pouco discutido. Em vez de escalar instâncias de um mesmo sistema, replica‑se a stack inteira em unidades independentes chamadas cells. Cada cell serve um subconjunto da base de usuários e contém tudo o que precisa para operar de forma autônoma.

Quando escalamos microserviços horizontalmente, normalmente fazemos isso:

• Deploy único → um bug pode derrubar todo o sistema.
• Cliente com tráfego intenso → degrada a experiência de todos (o famoso noisy neighbor).
• Falha em cascata → propaga pelo sistema inteiro.

A escala horizontal resolve capacidade, mas não isolamento.

Benefícios da Cell‑Based Architecture

1. Blast Radius Containment

Se a Cell 2 falha, apenas os usuários entre 1 M e 2 M são afetados. Os demais continuam operando normalmente.

2. Noisy Neighbor Isolation

Um cliente corporativo com milhões de requisições por dia não consegue impactar as outras cells.

3. Canary Deployment Natural

1. Deploy na Cell 1.
2. Monitora por ~30 min.
3. Se tudo OK, propaga para as demais cells.

Sem feature flags complexos; o rollback é simples porque afeta apenas uma cell.

4. Compliance e Isolamento por Região

Precisa garantir que dados de clientes europeus permaneçam na Europa?
Cells por região resolvem isso de forma estrutural, não como uma camada adicional de configuração.

Cell Router

O único componente verdadeiramente global. Ele recebe a requisição, consulta um store leve que mapeia tenant_id → cell_id e encaminha para a cell correta:

Request
   |
   v
Cell Router  -->  Cell N

Mas isso não é só sharding?

Não exatamente. Sharding é uma estratégia de banco de dados que distribui dados em partições. A Cell‑Based Architecture vai além, isolando também a lógica de aplicação, a camada de cache, os workers e demais recursos.

Desafios Operacionais

• Agregação de dados: consultas que precisam combinar informações de todas as cells exigem acesso a múltiplos bancos, aumentando a complexidade de pipelines e a necessidade de garantir consistência.
• Sobrecarga de uma cell: se uma cell recebe mais tráfego que o esperado, migrar usuários ou escalar sem downtime pode ser complicado. A redistribuição de dados requer planejamento cuidadoso e mecanismos seguros de migração.
• Versionamento de schema: alterações de schema, índices ou procedures precisam ser aplicadas em todos os N bancos. Isso demanda automação, estratégia de versionamento e rollout gradual.

Em suma, a Cell‑Based Architecture oferece uma solução robusta e escalável, mas traz novos desafios operacionais. Toda decisão arquitetural resolve alguns problemas e, inevitavelmente, introduz outros que precisam ser gerenciados.