Lab 31 — Quebrar o monolito pelo corte certo

{
  "pedidoId": "b6f2a9d4-2e1a-4b3c-9a7f-1c8d6e0f2a11",
  "produtoId": "f1a2b3c4-5678-4abc-9def-0123456789ab",
  "nomeProdutoNoMomento": "Cadeira de escritorio ergonomica",
  "criadoEm": "2026-08-07T14:22:31.618Z"
}

# extracao.tf — a infraestrutura do corte: banco proprio, fila, e os dois papeis

# ── O banco do servico extraido. Nao e o mesmo RDS do monolito. ───────────────
resource "aws_db_instance" "notificacoes" {
  identifier     = "${var.projeto}-notificacoes"
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.t4g.micro" # volume baixo: so o log de envio, sem pedido nem catalogo

  db_name  = "notificacoes"
  username = "app"
  manage_master_user_password = true # segredo gerenciado pelo Secrets Manager, nunca em variavel

  allocated_storage = 20
  db_subnet_group_name   = aws_db_subnet_group.privada.name
  vpc_security_group_ids = [aws_security_group.rds_notificacoes.id]

  # Um ALTER TABLE aqui nao trava NENHUMA tabela do monolito: e um banco fisicamente
  # separado. E o ponto central do padrao "database per service".
  skip_final_snapshot = false
  final_snapshot_identifier = "${var.projeto}-notificacoes-final"
}

# O security group do RDS aceita conexao SO da task de notificacoes — nunca
# 0.0.0.0/0, e nunca a task do monolito, que nao tem nada para ler ali.
resource "aws_security_group_rule" "rds_notificacoes_entrada" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.rds_notificacoes.id
  source_security_group_id = aws_security_group.task_notificacoes.id
}

# ── A fila entre os dois servicos, com DLQ dedicada. ───────────────────────────
resource "aws_sqs_queue" "pedido_criado_dlq" {
  name                      = "${var.projeto}-pedido-criado-dlq"
  message_retention_seconds = 1209600 # 14 dias — o teto do SQS; da tempo de investigar sem perder a mensagem
}

resource "aws_sqs_queue" "pedido_criado" {
  name = "${var.projeto}-pedido-criado"

  # Nao alteramos o padrao de 30s de visibility timeout aqui de proposito: o
  # consumidor processa em centenas de ms, entao o padrao ja sobra. So vale
  # revisar se o processamento (envio via SES) ficar lento o suficiente para a
  # mensagem voltar a ficar visivel ANTES de terminar — meça no seu ambiente.
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.pedido_criado_dlq.arn
    maxReceiveCount      = 5 # cinco tentativas: falha transitoria se recupera antes disso
  })
}

# Quem pode escrever na fila e o SEGREDO de nao virar chamada sincrona: e o
# outbox worker do monolito, e mais ninguem.
resource "aws_sqs_queue_policy" "somente_outbox_publica" {
  queue_url = aws_sqs_queue.pedido_criado.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { AWS = aws_iam_role.task_monolito.arn }
      Action    = "sqs:SendMessage"
      Resource  = aws_sqs_queue.pedido_criado.arn
    }]
  })
}

# ── Papel de tarefa do MONOLITO: so pode ENVIAR para a fila, nada alem disso. ──
data "aws_iam_policy_document" "monolito_publica_evento" {
  statement {
    effect    = "Allow"
    actions   = ["sqs:SendMessage"]
    resources = [aws_sqs_queue.pedido_criado.arn] # restrito a UMA fila; sem "*"
  }
}

# ── Papel de tarefa do servico de NOTIFICACOES: consome a fila e envia e-mail. ─
data "aws_iam_policy_document" "notificacoes_consome_e_envia" {
  statement {
    effect  = "Allow"
    actions = ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"]
    resources = [aws_sqs_queue.pedido_criado.arn] # restrito a mesma fila; sem "*"
  }
  statement {
    effect  = "Allow"
    actions = ["ses:SendEmail", "ses:SendRawEmail"]
    # Restrito a IDENTIDADE verificada, nao a conta inteira: o servico so pode
    # enviar EM NOME do dominio da Cadencia, nunca se passar por outro remetente.
    resources = [aws_ses_domain_identity.cadencia.arn]
  }
}

resource "aws_ecs_service" "notificacoes" {
  name            = "${var.projeto}-notificacoes"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.notificacoes.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  # Reusa o mesmo par mínimo/máximo do L03 — o rollout sem janela nao e
  # exclusivo do monolito; e propriedade de QUALQUER servico ECS bem configurado.
  deployment_minimum_healthy_percent = 100
  deployment_maximum_percent         = 200
  deployment_circuit_breaker { enable = true, rollback = true }

  network_configuration {
    subnets          = aws_subnet.privada[*].id
    security_groups  = [aws_security_group.task_notificacoes.id]
    assign_public_ip = false
  }
  # Sem load_balancer: este servico nao tem rota publica, so consome fila.
}

output "fila_pedido_criado" {
  value       = aws_sqs_queue.pedido_criado.url
  description = "URL da fila; o monolito publica aqui depois do commit"
}

// OutboxMessage.cs — a linha que garante que publicar nao e um passo separado do commit

public class OutboxMessage
{
    public Guid Id { get; set; }
    public string TipoEvento { get; set; } = "PedidoCriado";
    public string PayloadJson { get; set; } = default!;
    public DateTimeOffset CriadoEm { get; set; }
    public DateTimeOffset? PublicadoEm { get; set; } // null = ainda nao publicado
}

// PedidoService.cs — o ponto em que a garantia nasce
public async Task<Pedido> CriarPedidoAsync(NovoPedidoDto dto, AppDb db)
{
    // A verificacao de estoque e o decremento acontecem AQUI, na mesma
    // transacao do pedido — e e por isso que estoque NAO foi extraido.
    var produto = await db.Produtos.FindAsync(dto.ProdutoId)
        ?? throw new ProdutoNaoEncontradoException(dto.ProdutoId);
    if (produto.QuantidadeDisponivel < dto.Quantidade)
        throw new EstoqueInsuficienteException(dto.ProdutoId);
    produto.QuantidadeDisponivel -= dto.Quantidade;

    var pedido = new Pedido
    {
        Id = Guid.NewGuid(),
        ProdutoId = produto.Id,
        // Preco e nome SNAPSHOTADOS para dentro do pedido — e o que torna
        // Catalogo um candidato valido a extrair depois, sem quebrar pedido antigo.
        PrecoNoMomento = produto.Preco,
        NomeProdutoNoMomento = produto.Nome,
        Quantidade = dto.Quantidade,
        CriadoEm = DateTimeOffset.UtcNow,
    };
    db.Pedidos.Add(pedido);

    // A linha de outbox entra no MESMO SaveChanges do pedido. Ou as duas
    // sao commitadas juntas, ou nenhuma e — isto e o que fecha o dual-write
    // problem: nunca existe um pedido salvo sem a intencao de publicar salva.
    db.OutboxMessages.Add(new OutboxMessage
    {
        Id = Guid.NewGuid(),
        TipoEvento = "PedidoCriado",
        PayloadJson = JsonSerializer.Serialize(new PedidoCriadoEvento(
            pedido.Id, pedido.ProdutoId, pedido.NomeProdutoNoMomento, pedido.CriadoEm)),
        CriadoEm = DateTimeOffset.UtcNow,
    });

    await db.SaveChangesAsync(); // UM commit; pedido e outbox nascem juntos ou nao nascem
    return pedido;
}

// OutboxPublisherWorker.cs — o unico lugar que fala com a fila do lado do monolito

public class OutboxPublisherWorker(
    IServiceScopeFactory scopeFactory, IAmazonSQS sqs, IConfiguration config,
    ILogger<OutboxPublisherWorker> log) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        var filaUrl = config["Filas:PedidoCriado"]!;

        while (!ct.IsCancellationRequested)
        {
            using var escopo = scopeFactory.CreateScope();
            var db = escopo.ServiceProvider.GetRequiredService<AppDb>();

            // So le o que ainda nao foi publicado. A leitura NAO precisa de
            // lock especial: se dois workers rodassem em paralelo (nao roda,
            // desired_count controla isto por task), publicar duas vezes seria
            // absorvido pela idempotencia do CONSUMIDOR, nao daqui.
            var pendentes = await db.OutboxMessages
                .Where(m => m.PublicadoEm == null)
                .OrderBy(m => m.CriadoEm)
                .Take(50)
                .ToListAsync(ct);

            foreach (var msg in pendentes)
            {
                try
                {
                    await sqs.SendMessageAsync(new SendMessageRequest
                    {
                        QueueUrl = filaUrl,
                        MessageBody = msg.PayloadJson,
                        MessageAttributes = new()
                        {
                            ["TipoEvento"] = new MessageAttributeValue
                            { DataType = "String", StringValue = msg.TipoEvento },
                        },
                    }, ct);

                    msg.PublicadoEm = DateTimeOffset.UtcNow;
                }
                catch (Exception ex)
                {
                    // Nao marca como publicado. Fica pendente e tenta de novo
                    // no proximo ciclo — e a fila fora do ar NAO perde o pedido.
                    log.LogWarning(ex, "falha ao publicar outbox {Id}; tenta de novo no proximo ciclo", msg.Id);
                }
            }
            await db.SaveChangesAsync(ct);

            // O intervalo domina o atraso percebido na confirmacao — ver a
            // formula na secao de arquitetura de producao.
            await Task.Delay(TimeSpan.FromSeconds(2), ct);
        }
    }
}

// NotificacaoConsumerWorker.cs — o lado que le a fila e decide se envia

public class NotificacaoConsumerWorker(
    IAmazonSQS sqs, IAmazonSimpleEmailService ses, IServiceScopeFactory scopeFactory,
    IConfiguration config, ILogger<NotificacaoConsumerWorker> log) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        var filaUrl = config["Filas:PedidoCriado"]!;

        while (!ct.IsCancellationRequested)
        {
            var resposta = await sqs.ReceiveMessageAsync(new ReceiveMessageRequest
            {
                QueueUrl = filaUrl,
                MaxNumberOfMessages = 10,
                WaitTimeSeconds = 20, // long polling: evita custo e latencia de sondar vazio
            }, ct);

            foreach (var msg in resposta.Messages)
            {
                var evento = JsonSerializer.Deserialize<PedidoCriadoEvento>(msg.Body)!;
                using var escopo = scopeFactory.CreateScope();
                var db = escopo.ServiceProvider.GetRequiredService<NotificacaoDb>();

                // A CHECAGEM QUE IMPORTA. SQS padrao entrega PELO MENOS uma vez,
                // entao esta mensagem pode ser a segunda entrega da mesma
                // notificacao. E a linha abaixo, nao a fila, que impede o
                // segundo e-mail.
                var jaEnviado = await db.EnviosLog
                    .AnyAsync(e => e.PedidoId == evento.PedidoId, ct);

                if (!jaEnviado)
                {
                    await ses.SendEmailAsync(MontarEmailConfirmacao(evento), ct);
                    db.EnviosLog.Add(new EnvioLog
                    {
                        PedidoId = evento.PedidoId,
                        EnviadoEm = DateTimeOffset.UtcNow,
                    });
                    await db.SaveChangesAsync(ct);
                }
                else
                {
                    log.LogInformation("pedido {Id} ja tinha e-mail enviado; mensagem reentregue, ignorada",
                        evento.PedidoId);
                }

                // So apaga DEPOIS do envio (ou da checagem) ter sucesso. Se o
                // processo cair entre enviar e apagar, a reentrega vai bater
                // no log e nao reenviar — a mesma checagem cobre os dois casos.
                await sqs.DeleteMessageAsync(filaUrl, msg.ReceiptHandle, ct);
            }
        }
    }
}

# provas.sh — cinco medicoes; nenhuma conclusao vem de "parece que funcionou"

PROJETO=ffv-lab; REGIAO=us-east-1
FILA=$(terraform output -raw fila_pedido_criado)

# ── Prova 1: mudar so notificacao nao re-testa pedido ────────────────────────
# Antes do corte: 2.400 asserções, ~40 min. Depois, so a suite do servico
# extraido roda para uma mudanca de template.
time dotnet test src/Notificacoes.Tests --filter Categoria=Notificacao
# Esperado: suite do servico de notificacoes sozinha, na ordem de segundos a
# poucos minutos — nao os ~40 min da suite inteira do monolito.

# ── Prova 2: pedido sobrevive ao servico de notificacoes fora do ar ──────────
aws ecs update-service --cluster $PROJETO --service ${PROJETO}-notificacoes --desired-count 0
curl -s -o /dev/null -w '%{http_code}\n' -X POST "$API/pedidos" -d @exemplo-pedido.json
# Esperado: 201. O pedido existe no banco do monolito mesmo com notificacoes a zero.
aws sqs get-queue-attributes --queue-url "$FILA" \
  --attribute-names ApproximateNumberOfMessages --query 'Attributes.ApproximateNumberOfMessages'
# Esperado: >= 1 — a mensagem ficou retida esperando o consumidor voltar.
aws ecs update-service --cluster $PROJETO --service ${PROJETO}-notificacoes --desired-count 2

# ── Prova 3: reentrega da fila nao duplica e-mail ─────────────────────────────
# Forca reentrega: recebe sem apagar (simula falha do consumidor apos enviar).
MSG=$(aws sqs receive-message --queue-url "$FILA" --visibility-timeout 1 \
  --query 'Messages[0].Body' --output text)
sleep 2  # o timeout de 1s expira; a mensagem volta a ficar visivel
aws ses get-send-statistics --query 'SendDataPoints[-1].DeliveryAttempts'
# Esperado: 1 envio real no SES, mesmo com 2 entregas da fila — a checagem por
# pedido_id no consumidor absorveu a segunda.

# ── Prova 4: o outbox nao perde o evento com a fila fora do ar ───────────────
aws sqs set-queue-attributes --queue-url "$FILA" --attributes Policy='{}'  # nega temporariamente
curl -s -X POST "$API/pedidos" -d @exemplo-pedido.json
psql -c "select count(*) from outbox_messages where publicado_em is null;"
# Esperado: >= 1 linha pendente — o pedido existe, o evento so nao foi publicado ainda.
# restaure a policy da fila e rode de novo:
psql -c "select count(*) from outbox_messages where publicado_em is null;"
# Esperado: 0 — o worker publicou assim que a fila voltou a aceitar.

# ── Prova 5: mensagem envenenada vai para a DLQ apos 5 tentativas ────────────
aws sqs send-message --queue-url "$FILA" --message-body '{"pedidoId":"nao-existe"}'
# consumidor lanca excecao de desserializacao 5 vezes (maxReceiveCount)
sleep 60
DLQ=$(terraform output -raw fila_dlq 2>/dev/null || echo "${PROJETO}-pedido-criado-dlq")
aws sqs get-queue-attributes --queue-url "$DLQ" \
  --attribute-names ApproximateNumberOfMessages --query 'Attributes.ApproximateNumberOfMessages'
# Esperado: 1 — a mensagem saiu da fila principal e nao voltou em laço.

# 1. Antes de destruir, confira se ha mensagem retida — apagar a fila com
#    mensagem dentro PERDE a confirmacao de pedidos que ainda nao foram notificados.
aws sqs get-queue-attributes --queue-url "$(terraform output -raw fila_pedido_criado)" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
# Se houver mensagem, espere o consumidor drenar ou copie o conteudo antes de seguir.

# 2. Confira tambem a DLQ — mensagem la e exatamente o que faltou investigar.
aws sqs get-queue-attributes --queue-url "$(terraform output -raw fila_dlq)" \
  --attribute-names ApproximateNumberOfMessages

# 3. Derrube o que o Terraform administra.
terraform destroy -auto-approve

# 4. SNAPSHOT FINAL DO RDS DE NOTIFICACOES: com skip_final_snapshot = false, o
#    destroy cria um snapshot que SOBREVIVE e cobra armazenamento indefinidamente.
aws rds describe-db-snapshots \
  --db-instance-identifier ffv-lab-notificacoes \
  --query "DBSnapshots[].DBSnapshotIdentifier" --output table
# apague o que nao precisar manter:
# aws rds delete-db-snapshot --db-snapshot-identifier <id>

# 5. IDENTIDADE VERIFICADA NO SES: nao cobra parada, mas fica registrada na conta.
aws ses list-identities --identity-type Domain

# 6. Prova final: nada com o nome do projeto de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab \
  --query "ResourceTagMappingList[].ResourceARN" --output table