Na era cloud-native, escalar uma arquitetura frequentemente resulta em um sistema massivo e altamente interconectado, onde uma única falha pode causar uma indisponibilidade global. A Arquitetura Celular (Cellular Architecture) resolve esse problema ao decompor o sistema em domínios independentes e isolados de falha, chamados de cells.
Neste tutorial, você irá construir uma arquitetura altamente resiliente e orientada a eventos utilizando o padrão celular combinado com um fluxo assíncrono baseado em:
-
DynamoDB Streams
-
AWS Lambda
-
Amazon SNS
-
Amazon SQS
Em vez de operar com um único plano de dados monolítico, você implantará múltiplas cópias idênticas da infraestrutura (cells). Uma camada fina de roteamento na borda irá inspecionar as requisições de entrada e encaminhá-las para a célula apropriada com base em uma chave de partição, como o ID do tenant.
Se um evento problemático (poison pill) ou uma degradação localizada afetar uma célula específica, o impacto permanecerá restrito apenas àquela célula, garantindo máxima disponibilidade para os demais tenants do sistema.
Essa abordagem cria um limite definitivo de isolamento de falhas para sistemas distribuídos críticos.
2. Pré-requisitos
Para executar essa arquitetura, você precisará:
-
Uma conta AWS ativa com permissões administrativas.
-
Terraform versão 1.3.0 ou superior instalado.
-
AWS CLI configurado com suas credenciais.
-
Conhecimento sobre:
-
Control Plane vs Data Plane
-
Domain-Driven Design (DDD)
-
Arquiteturas orientadas a eventos
-
DynamoDB, Lambda, SNS e SQS
-
3. Passo a Passo
Passo 1: Definindo o módulo da célula do Data Plane
O que fazer
Crie um módulo reutilizável no Terraform encapsulando todo o pipeline orientado a eventos:
-
DynamoDB
-
SNS
-
SQS
-
Lambdas
Esse módulo representa uma célula isolada e autocontida.
Por que isso é importante
O principal fundamento da arquitetura celular é a repetibilidade.
Ao transformar o plano de dados em um módulo, cada célula se torna uma cópia idêntica e determinística da infraestrutura.
Isso garante que:
-
Uma fila SQS sobrecarregada na célula Alpha não impacte a Beta.
-
Um throttling no DynamoDB de uma célula não afete as demais.
-
O isolamento estrutural seja mantido.
Exemplo Terraform
variable "cell_id" {
description = "Identificador único da célula"
type = string
}
resource "aws_dynamodb_table" "cell_table" {
name = "app-data-cell-${var.cell_id}"
billing_mode = "PAY_PER_REQUEST"
hash_key = "id"
attribute {
name = "id"
type = "S"
}
stream_enabled = true
stream_view_type = "NEW_AND_OLD_IMAGES"
}
resource "aws_sns_topic" "cell_topic" {
name = "processing-topic-cell-${var.cell_id}"
}
resource "aws_sqs_queue" "cell_queue" {
name = "processing-queue-cell-${var.cell_id}"
}Passo 2: Instanciando células independentes
O que fazer
No Terraform principal, instancie múltiplas células independentes.
Por que isso importa
Aqui você cria os limites físicos de isolamento.
Exemplo:
-
Clientes enterprise podem possuir células dedicadas.
-
Problemas de “noisy neighbor” deixam de existir.
-
Você prepara o ambiente para expansão multi-cloud ativa no futuro.
Exemplo
module "cell_alpha" {
source = "./modules/event_driven_cell"
cell_id = "alpha"
}
module "cell_beta" {
source = "./modules/event_driven_cell"
cell_id = "beta"
}
module "cell_gamma" {
source = "./modules/event_driven_cell"
cell_id = "gamma"
}Passo 3: Criando o Control Plane
O que fazer
Crie uma tabela global no DynamoDB responsável por mapear:
-
Tenant ID
-
Cell ID
Por que isso importa
A camada de roteamento precisa descobrir dinamicamente para qual célula enviar cada requisição.
Esse mapeamento não pode ser hardcoded.
Exemplo
resource "aws_dynamodb_table" "tenant_routing_map" {
name = "global-tenant-cell-mapping"
billing_mode = "PAY_PER_REQUEST"
hash_key = "tenant_id"
attribute {
name = "tenant_id"
type = "S"
}
}Passo 4: Implementando o Cell Router
O que fazer
Crie:
-
Amazon API Gateway
-
Lambda Router
Esse Lambda irá:
-
Extrair o Tenant ID da requisição
-
Consultar a tabela global de roteamento
-
Descobrir a célula correta
-
Inserir os dados no DynamoDB daquela célula
Por que isso importa
O roteador deve ser extremamente fino (thin router).
Ele não deve conter regras de negócio.
Toda lógica deve permanecer dentro das células.
Após o roteamento inicial, o pipeline assíncrono assume:
DynamoDB Streams
→ Producer Lambda
→ SNS
→ SQS
→ Consumer LambdaExemplo Terraform
resource "aws_lambda_function" "cell_router" {
function_name = "global-edge-router"
handler = "router.handler"
runtime = "nodejs20.x"
}Problemas comuns
Dependências entre células
O erro mais grave é permitir que células compartilhem recursos.
Exemplo errado:
-
Uma célula consultar dados diretamente de outra
-
Compartilhar um banco RDS centralizado
-
Compartilhar buckets críticos
Isso quebra completamente o isolamento.
Cada célula deve possuir seus próprios dados.
Gargalo no Control Plane
Se o Router consultar o DynamoDB a cada requisição:
-
A latência aumenta
-
O DynamoDB sofre throttling
Solução:
-
Implementar cache em memória no Lambda Router.
Poison Pills e falhas assíncronas
Se um payload inválido quebrar o Consumer Lambda:
-
A mensagem ficará circulando na fila SQS.
A vantagem da arquitetura celular é que isso afeta apenas uma célula.
A solução correta é utilizar:
-
Dead Letter Queue (DLQ)
5. Conclusão
Ao combinar arquitetura celular com sistemas orientados a eventos, você cria uma plataforma extremamente resiliente e com blast radius controlado.
A separação entre:
-
Control Plane global
-
Data Planes isolados
garante que falhas permaneçam matematicamente contidas.
Com Terraform Modules, você consegue:
-
Padronização
-
Escalabilidade linear
-
Reprodutibilidade
-
Isolamento de falhas
Conforme a arquitetura evoluir, você pode integrar:
-
Amazon Route 53 ARC
-
Estratégias de disaster recovery
-
Cell shifting automático
-
Arquiteturas multi-cloud ativas
O resultado é uma infraestrutura preparada para aplicações distribuídas de missão crítica em larga escala.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?