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 agregar dados de todas as cells, será preciso consultar e processar informações distribuídas em múltiplos bancos. Isso pode aumentar a complexidade das consultas, dos pipelines de dados e da consistência das informações.
Outro ponto importante é a sobrecarga de uma cell específica. Se uma cell começar a receber mais tráfego do que o esperado, migrar usuários ou aumentar sua capacidade sem downtime pode ser bem mais complicado. Como os bancos são separados, a redistribuição de dados exige mais cuidado, planejamento e mecanismos seguros de migração.
Além disso, qualquer mudança estrutural no banco, como alterações de schema, índices ou procedures, precisa ser aplicada em todos os N bancos existentes. Isso exige uma boa estratégia de versionamento, automação e rollout gradual.
Ou seja, apesar de ser uma solução robusta e escalável, ela também traz novos desafios operacionais. Toda decisão arquitetural resolve alguns problemas, mas inevitavelmente adiciona outros.