Arquitetura orientada a eventos: o blueprint da AWS para sistemas resilientes e prontos para IA

Um blueprint publicado no AWS Builder Center propõe trocar o scaling monolítico por filas, idempotência e observabilidade de ponta a ponta. O ganho prático para quem opera em produção é menos conexão de banco estourada e menos conta de IA fora de controle.

Nota da redação: a fonte original confirma a exigência de idempotência no processamento de filas, mas não especifica que o registro de idempotência seja armazenado no Amazon DynamoDB. Essa associação específica (etapa 3 do fluxo, e menção na seção "Como adaptar") é uma elaboração editorial baseada em um padrão comum de arquitetura AWS, não uma afirmação textual do material da AWS. Leve isso em conta ao avaliar esse detalhe da arquitetura.

Um blueprint publicado no AWS Builder Center propõe trocar o scaling monolítico por filas, idempotência e observabilidade de ponta a ponta. O ganho prático para quem opera em produção é menos conexão de banco estourada e menos conta de IA fora de controle.

O problema

Quando uma aplicação engasga em produção, a reação automática costuma ser aumentar a capacidade de computação: mais instâncias, mais réplicas, mais memória. O problema é que escalar só a camada de aplicação, sem tocar na persistência nem nos fluxos síncronos, não resolve o gargalo: ele só move o gargalo para um lugar mais caro de consertar.

Foi esse o argumento publicado pelo engenheiro Caleb Cheptumo em 4 de novembro de 2026 no AWS Builder Center. Segundo ele, três falhas se repetem quando times escalam compute sem escalar o resto do sistema: exaustão de conexões de banco quando o auto scaling group salta de duas para vinte instâncias, estouro de orçamento quando modelos de linguagem são chamados sem limite por token, e impossibilidade prática de garantir conformidade de privacidade quando os dados do usuário estão espalhados em múltiplos serviços sem orquestração central.

As arquiteturas mais duradouras tratam a infraestrutura como descartável, a lógica de negócio como prioridade máxima, e as falhas como condições esperadas, a serem roteadas e observadas.

The most durable architectures treat infrastructure as disposable, business logic as paramount, and failures as expected conditions to be routed and observed.Caleb Cheptumo, AWS Builder Center

A saída proposta não é um serviço novo, é um padrão: decompor o fluxo síncrono em eventos assíncronos, proteger a camada de dados antes de escalar o front, tratar IA como workload de custo variável e instrumentar tudo com telemetria granular. Para quem arquiteta ou opera ambiente AWS em produção, o valor está em quais decisões de design esse padrão força antes do incidente acontecer.

A arquitetura

O fluxo descrito vai do pedido do usuário até a purga de dados, passando por três camadas de proteção. Em termos de diagrama, os passos seriam:

1. O cliente envia uma requisição (por exemplo, upload de um documento) para a API, via AWS AppSync.
2. Em vez de processar na hora, a requisição é publicada em uma fila (Amazon SQS) ou roteada por evento (Amazon EventBridge), liberando a resposta ao cliente imediatamente.
3. Uma função AWS Lambda consome a fila. Antes de processar, ela verifica um registro de idempotência em um padrão de acesso bem modelado no Amazon DynamoDB, para garantir que a entrega duplicada do SQS não gere cobrança dupla nem registro duplicado.
4. Se a tarefa envolve linguagem natural, um modelo pequeno local (1 a 8 bilhões de parâmetros, rodando em NPU do dispositivo) faz a triagem: sanitiza PII e responde consultas simples sem round-trip de rede.
5. Só o que exige raciocínio complexo ou janela de contexto grande escala para um modelo de fronteira hospedado no Amazon Bedrock.
6. Para dados não estruturados em larga escala, o Amazon Comprehend extrai entidades, sentimento e PII antes de qualquer gravação.
7. Quando a função Lambda precisa falar com o banco relacional, ela não abre conexão direta: passa pelo Amazon RDS Proxy, que multiplexa milhares de conexões de aplicação sobre um pool pequeno de conexões reais.
8. Leituras repetidas e sensíveis a latência são resolvidas primeiro no Amazon ElastiCache, antes de bater no banco.
9. Mensagens que falham repetidamente são roteadas para uma Dead-Letter Queue, em vez de entrar em retry infinito.
10. Toda a cadeia emite telemetria via AWS Distro for OpenTelemetry (ADOT): traces vão para o AWS X-Ray, métricas para o Amazon CloudWatch, logs para o CloudWatch Logs com retenção configurada e, quando é log de compliance, também seguem via Amazon Data Firehose para o Amazon S3, consultável depois pelo Amazon Athena.
11. Quando um usuário invoca o direito ao esquecimento, uma máquina de estado no AWS Step Functions consulta um registro no DynamoDB, dispara workers de exclusão em paralelo (banco, S3, OpenSearch) e loga o resultado usando identificador anonimizado, nunca o e-mail ou PII real do usuário.

Os serviços envolvidos

Nenhum desses serviços é novidade isolada; o ponto do blueprint é a composição. RDS Proxy sem fila na frente não evita o pico de conexão se a Lambda ainda dispara em rajada. Step Functions sem registro central no DynamoDB não sabe onde o dado do usuário está espalhado.

Trade-offs

Idempotência é o primeiro custo de engenharia: toda função que consome SQS precisa de uma chave de deduplicação e uma gravação condicional antes de processar, porque o SQS garante entrega pelo menos uma vez, nunca exatamente uma vez. Isso é mais código, mais teste e mais caso de borda, mas evita cobrar o cliente duas vezes por um pico de latência. É o pilar de confiabilidade do Well-Architected pagando a conta antecipadamente.

A triagem de IA na borda (edge triage) reduz latência e custo de token, mas introduz o modelo pequeno como mais uma peça a versionar, atualizar e monitorar no dispositivo. Times que não têm fleet management maduro para esse modelo local tendem a pagar essa complexidade sem colher o benefício completo. Aqui o trade-off cruza eficiência de desempenho com excelência operacional: a arquitetura fica mais rápida, a operação fica mais pesada.

RDS Proxy e ElastiCache adicionam um componente gerenciado a mais na conta e na superfície de falha, mas evitam o cenário mais caro: banco saturado derrubando toda a aplicação porque ninguém limitou conexão. É uma troca clássica de otimização de custos contra resiliência: pagar um pouco mais em regime normal para não pagar muito mais em incidente. Zero-trust com IAM Identity Center entra no pilar de segurança: credenciais de curta duração reduzem a janela de exploração de uma chave vazada, ao custo de mais fricção na configuração inicial de cada conta.

Custo estimado

O material da AWS não publica números de preço, e por isso vale evitar estimativa sem base documental. O que dá para afirmar com segurança, a partir do blueprint, é a lógica de design: desacoplar o consumo da fila do tamanho da frota de Lambda evita manter instância ociosa esperando pico, e o limite multi-dimensional de token, requisição concorrente e orçamento por tenant funciona como proteção financeira direta para cargas de IA, não só como controle de qualidade de serviço. Para o detalhe exato de cobrança de cada serviço (SQS, EventBridge, RDS Proxy, ElastiCache, Bedrock), a referência é a página de preços oficial de cada produto, não este blueprint.

O vazamento de custo mais citado no material é silencioso: CloudWatch Log Groups sem política de retenção configurada guardam log para sempre, por padrão. Para quem opera o ambiente, o comando que fecha esse buraco é simples:

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

aws logs put-retention-policy \
 --log-group-name /aws/lambda/minha-funcao \
 --retention-in-days 30

Para log de compliance que precisa ficar disponível por mais tempo mas é consultado raramente, a recomendação é tirá-lo do CloudWatch Logs via Data Firehose para o S3, onde o armazenamento é mais barato, e consultar sob demanda com Athena em vez de manter índice quente o tempo todo. Para dimensionar o custo real da sua carga em sa-east-1, a Calculadora de Preços da AWS continua sendo o caminho mais confiável, já que os valores por serviço mudam com frequência maior do que este texto consegue acompanhar.

Como adaptar

Nem todo sistema precisa das onze etapas do fluxo descrito. Equipe pequena com tráfego baixo e sem IA no caminho crítico pode adotar só os dois primeiros blocos: fila na frente do Lambda e idempotência via DynamoDB, deixando RDS Proxy para quando o número de conexões simultâneas realmente virar problema.

Quem já roda Bedrock mas ainda não tem fleet de NPU em produção pode pular a camada de triagem na borda sem perder o essencial do padrão: o limite multi-dimensional de token e orçamento por tenant funciona mesmo sem modelo local, só entrega menos economia de latência.

Para o time de SRE que vive de dashboard do CloudWatch, o ponto de entrada mais barato de implementar primeiro é a observabilidade: plugar o ADOT como coletor único, padronizar retenção de log e garantir que todo trace de erro em Lambda chegue ao X-Ray antes de mexer em qualquer coisa na camada de dados. Sem essa visibilidade, qualquer mudança nas outras camadas vira experimento às cegas.

O Step Functions para purga de dados só compensa a complexidade quando o sistema já tem dado espalhado em três ou mais serviços (banco, S3, índice de busca). Se o dado do usuário mora inteiro em uma tabela DynamoDB, um delete_item com o registro certo resolve o direito ao esquecimento sem precisar de máquina de estado.

Fonte: AWS Builder Center, "Architecting for Scale: A Blueprint for Resilient, AI-Ready Systems on AWS", por Caleb Cheptumo (https://builder.aws.com/content/3Ld5SyT0Uq8bnfToDGVCXWIuKtb/architecting-for-scale-a-blueprint-for-resilient-ai-ready-systems-on-aws).

Fonte: AWS Builder Center