Como Otimizar Custos e Escalabilidade na AWS Usando Arquiteturas Serverless Baseadas em Eventos

À medida que as aplicações crescem, garantir alta disponibilidade e escalabilidade sem disparar os custos de infraestrutura torna-se um dos maiores desafios do time de engenharia.

Modelos tradicionais baseados em servidores pré-alocados frequentemente resultam em subutilização de recursos. Neste artigo, vamos explorar como migrar de uma abordagem monolítica/síncrona para uma **Arquitetura Baseada em Eventos (Event-Driven Architecture - EDA)** utilizando serviços *Serverless* nativos da AWS, alcançando redução de custos e resiliência quase instantânea.

---

### O Problema: Acoplamento Síncrono e Custos Ociosos

Considere um sistema de processamento de pedidos em e-commerce: 1. O cliente faz uma compra. 2. A API processa o pagamento. 3. O estoque é atualizado. 4. O e-mail de confirmação é enviado. 5. A nota fiscal é gerada.

Quando todas essas etapas ocorrem de forma síncrona em uma única requisição HTTP, qualquer instabilidade em um serviço terceiro (como o gateway de pagamento ou emissor de NF) pode travar a requisição inteira, gerando *timeouts* e frustração para o usuário. Além disso, manter instâncias EC2 ou contêineres dimensionados para picos de tráfego resulta em desperdício de orçamento nos horários ociosos.

---

### A Solução: Arquitetura Decoplada na AWS

Ao adotar uma arquitetura baseada em eventos, cada etapa passa a ser tratada de forma assíncrona.

**Fluxo da Arquitetura:** * `Cliente` ➔ `Amazon API Gateway` ➔ `AWS Lambda (Criar Pedido)` ➔ `Amazon EventBridge` * O `Amazon EventBridge` roteia para filas dedicadas do `Amazon SQS`: * Fila 1 ➔ `AWS Lambda (Pagamento)` * Fila 2 ➔ `AWS Lambda (Estoque)` * Fila 3 ➔ `AWS Lambda (Notificação)`

#### Componentes-Chave: * **Amazon API Gateway & AWS Lambda:** Recebe o pedido e valida rapidamente os dados antes de publicar o evento. * **Amazon EventBridge:** Atua como o barramento central de eventos (*Event Bus*), roteando mensagens com base em regras configuradas. * **Amazon SQS (Simple Queue Service):** Garante a persistência e tolerância a falhas. Se a função Lambda de processamento falhar ou atingir *throttling*, o evento permanece na fila para novas tentativas (*retries*). * **Amazon DynamoDB:** Banco de dados NoSQL gerenciado para armazenar o estado das requisições com baixa latência e custo por uso.

---

### Exemplo Prático: Publicando um Evento no EventBridge com AWS SDK (Python/Boto3)

Abaixo está um exemplo simples mostrando como enviar um evento de pedido criado para o EventBridge:

```python import json import boto3

eventbridge_client = boto3.client('events')

def lambda_handler(event, context): order_data = json.loads(event['body']) # Publica o evento no EventBridge response = eventbridge_client.put_events( Entries=[ { 'Source': 'com.minhaempresa.pedidos', 'DetailType': 'PedidoCriado', 'Detail': json.dumps(order_data), 'EventBusName': 'default' } ] ) return { 'statusCode': 200, 'body': json.dumps({ 'message': 'Pedido recebido com sucesso!', 'eventId': response['Entries'][0]['EventId'] }) }