Lab 14 — Escolher o banco pela carga, no mesmo caso de uso

# Rode ANTES de qualquer mudança. O numero daqui e a linha de base.
CLIENTE="3f2a1c10-8e3a-4a11-9c2e-000000000001"
hey -z 20s -c 10 "$BASE_URL/clientes/$CLIENTE/pedidos" > /tmp/isolado.txt &
ISOLADO=$!
wait $ISOLADO
grep "95 %" /tmp/isolado.txt   # linha de base: 24 ms

curl -s "$BASE_URL/relatorios/faturamento?inicio=2026-01-01&fim=2026-08-01" -o /dev/null &
RELATORIO=$!
hey -z 20s -c 10 "$BASE_URL/clientes/$CLIENTE/pedidos" > /tmp/concorrente.txt
wait $RELATORIO
grep "95 %" /tmp/concorrente.txt
# Na Cadencia: 24 ms isolado, 310 ms com o relatorio rodando — treze vezes pior,
# sem NENHUM erro no log. E resposta 200 lenta, o pior tipo de defeito.

{
  "id": 88214,
  "pedido_id": "b7a1f0b0-2c44-4e9a-9d31-000000009182",
  "cliente_id": "3f2a1c10-8e3a-4a11-9c2e-000000000001",
  "loja_id": "a10ecb4e-6f21-4a02-8b9d-000000000512",
  "total": 187.90,
  "status": "confirmado",
  "criado_em": "2026-08-07T14:03:21.118Z",
  "processado_em": null
}

-- indices-historico-e-relatorio.sql — os dois índices que tornam a
-- comparação deste laboratório honesta. Sem eles, QUALQUER banco varre a
-- tabela inteira, e a diferença medida seria entre "com índice" e "sem
-- índice", não entre padrões de acesso.

-- O histórico por cliente: busca pontual em profundidade de árvore.
-- INCLUDE evita tocar a tabela para os campos que a listagem mostra
-- (index-only scan), e CONCURRENTLY evita travar escrita durante a criação.
CREATE INDEX CONCURRENTLY idx_pedidos_cliente_historico
    ON pedidos (cliente_id, criado_em DESC, id DESC)
    INCLUDE (loja_id, total, status);

-- O relatório de faturamento por loja e período usa ESTE índice — a chave
-- dele é a pergunta oposta à do histórico, e é por isso que um único índice
-- não serve às duas cargas igualmente bem.
CREATE INDEX CONCURRENTLY idx_pedidos_loja_periodo
    ON pedidos (loja_id, criado_em)
    INCLUDE (total);

-- A tabela que faz a escrita virar decisão em vez de acidente: toda
-- gravação de pedido grava também a intenção de projetar.
CREATE TABLE outbox_eventos (
    id            BIGSERIAL PRIMARY KEY,
    pedido_id     UUID NOT NULL,
    cliente_id    UUID NOT NULL,
    loja_id       UUID NOT NULL,
    total         NUMERIC(12,2) NOT NULL,
    status        TEXT NOT NULL,
    criado_em     TIMESTAMPTZ NOT NULL,
    processado_em TIMESTAMPTZ
);

-- O projetor varre só o que falta processar; sem este índice parcial, a
-- fila cresce e cada rodada do projetor voltaria a examinar linhas antigas
-- já projetadas.
CREATE INDEX CONCURRENTLY idx_outbox_pendente
    ON outbox_eventos (id)
    WHERE processado_em IS NULL;

-- EXPLAIN (ANALYZE, BUFFERS) antes e depois de cada índice é a prova de que
-- o planejador está USANDO o índice — "eu criei o índice" não é o mesmo que
-- "a consulta ficou mais barata".

# aurora.tf — o cluster que troca RDS por Aurora: mesma interface SQL,
# arquitetura de armazenamento diferente. É essa diferença que justifica um
# reader fresco sem manter uma segunda cópia dos dados.

resource "aws_rds_cluster" "pedidos" {
  cluster_identifier = "${var.projeto}-aurora"
  engine              = "aurora-postgresql"
  engine_version      = "16.4"
  database_name       = "pedidos"
  master_username     = "app_admin"

  # Segredo GERADO e rotacionado pelo Secrets Manager — nunca em texto aqui.
  # A aplicação lê a connection string por ARN, na definição da task.
  manage_master_user_password = true

  db_subnet_group_name   = aws_db_subnet_group.privada.name
  vpc_security_group_ids = [aws_security_group.banco.id]

  storage_encrypted = true
  kms_key_id         = aws_kms_key.app.arn

  backup_retention_period = 7
  preferred_backup_window = "03:00-04:00"

  # Sem isto, `terraform destroy` apaga o cluster E o histórico de backup
  # junto. O nome fica na seção de limpeza — é onde o custo esquecido mora.
  final_snapshot_identifier = "${var.projeto}-aurora-final-${formatdate("YYYYMMDD", timestamp())}"
  skip_final_snapshot       = false

  deletion_protection = true # removido explicitamente antes do destroy, de propósito
}

resource "aws_rds_cluster_instance" "writer" {
  identifier          = "${var.projeto}-aurora-writer"
  cluster_identifier  = aws_rds_cluster.pedidos.id
  instance_class      = "db.r6g.large"
  engine              = aws_rds_cluster.pedidos.engine
  engine_version      = aws_rds_cluster.pedidos.engine_version
  publicly_accessible = false
}

# A instância nova SE CONECTA ao volume que já existe — ela não copia dado
# nenhum antes de começar a servir. É por isso que promover uma leitora a
# escritora no failover não espera réplica "alcançar" o primário: as duas já
# liam o mesmo volume de cluster.
resource "aws_rds_cluster_instance" "reader" {
  identifier          = "${var.projeto}-aurora-reader"
  cluster_identifier  = aws_rds_cluster.pedidos.id
  instance_class      = "db.r6g.large"
  engine              = aws_rds_cluster.pedidos.engine
  engine_version      = aws_rds_cluster.pedidos.engine_version
  publicly_accessible = false

  # Não é uma segunda cópia dos dados: é uma segunda porta de entrada no
  # MESMO volume. O relatório lê daqui e nunca disputa CPU com o writer.
}

output "endpoint_escrita" {
  value       = aws_rds_cluster.pedidos.endpoint
  description = "sempre aponta para o writer atual, mesmo depois de um failover"
}

output "endpoint_leitura" {
  value       = aws_rds_cluster.pedidos.reader_endpoint
  description = "balanceia entre as instâncias leitoras; é para onde o relatório aponta"
}

# dynamodb.tf — a projeção do único caminho de leitura CONHECIDO de
# antemão. Chave de partição = cliente, porque é assim que a pergunta chega;
# a chave É o padrão de acesso, não uma escolha de modelagem solta no ar.

resource "aws_dynamodb_table" "historico_pedidos" {
  name = "${var.projeto}-historico-pedidos"

  # Sob demanda: o volume de escrita é 40 mil pedidos/dia, com pico de 20x
  # em campanha, e ainda não justifica o esforço de dimensionar capacidade
  # provisionada com auto scaling. Reavaliar quando o padrão de tráfego
  # ficar previsível o suficiente para provisionar sem desperdiçar.
  billing_mode = "PAY_PER_REQUEST"

  hash_key  = "PK" # CLIENTE#<id>
  range_key = "SK" # PEDIDO#<data ISO>#<id do pedido>

  attribute {
    name = "PK"
    type = "S"
  }
  attribute {
    name = "SK"
    type = "S"
  }

  point_in_time_recovery {
    enabled = true # restaura para qualquer segundo dos últimos 35 dias — a
                    # rede de segurança contra escrita ruim do projetor
  }

  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.app.arn
  }

  deletion_protection_enabled = true # removido explicitamente antes do destroy

  tags = {
    Projeto = var.projeto
  }
}

# Endpoint de GATEWAY — não de interface. A diferença custa caro confundir:
# o de gateway entra na TABELA DE ROTAS da sub-rede, sem interface de rede
# elástica e sem cobrança por hora. Só existe para S3 e DynamoDB; todo outro
# serviço regional (Bedrock, Secrets Manager) usa endpoint de INTERFACE, com
# ENI e cobrança por hora e por GB.
resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.principal.id
  service_name      = "com.amazonaws.${var.regiao}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.privada[*].id
}

# Política mínima da task role: a aplicação só lê e escreve NESTA tabela, e
# só com as operações que o repositório usa. Nenhuma ação de administração
# (CreateTable, DeleteTable) entra aqui — essa é responsabilidade do pipeline.
data "aws_iam_policy_document" "acesso_historico" {
  statement {
    effect = "Allow"
    actions = [
      "dynamodb:Query",
      "dynamodb:GetItem",
      "dynamodb:PutItem",
    ]
    resources = [aws_dynamodb_table.historico_pedidos.arn]
  }
}

output "tabela_historico" {
  value       = aws_dynamodb_table.historico_pedidos.name
  description = "nome da tabela; a chave é CLIENTE#<id> / PEDIDO#<data>#<id>"
}

// HistoricoRepositorioSql.cs — a MESMA classe atende RDS e Aurora: o
// protocolo de fio é idêntico, porque a diferença entre os dois está na
// arquitetura de armazenamento, não na interface SQL. Só a connection
// string muda entre os dois ambientes.

public sealed class HistoricoRepositorioSql : IHistoricoRepositorio
{
    private readonly NpgsqlDataSource _fonte;

    public HistoricoRepositorioSql(NpgsqlDataSource fonte) => _fonte = fonte;

    public async Task<PaginaHistoricoSql> BuscarAsync(
        Guid clienteId, DateTimeOffset? antesDe, int tamanho, CancellationToken ct)
    {
        // O índice idx_pedidos_cliente_historico é o que faz esta consulta
        // custar quase nada: é uma busca em profundidade de árvore pela
        // chave (cliente_id, criado_em DESC, id DESC), não uma varredura.
        const string sql = """
            SELECT id, loja_id, total, status, criado_em
            FROM pedidos
            WHERE cliente_id = @cliente
              AND (@antes_de::timestamptz IS NULL OR criado_em < @antes_de)
            ORDER BY criado_em DESC, id DESC
            LIMIT @tamanho
            """;

        await using var cmd = _fonte.CreateCommand(sql);
        cmd.Parameters.AddWithValue("cliente", clienteId);
        cmd.Parameters.AddWithValue("antes_de", (object?)antesDe ?? DBNull.Value);
        cmd.Parameters.AddWithValue("tamanho", tamanho + 1); // +1 revela se há próxima página

        var itens = new List<PedidoResumo>();
        await using var leitor = await cmd.ExecuteReaderAsync(ct);
        while (await leitor.ReadAsync(ct))
            itens.Add(new PedidoResumo(
                leitor.GetGuid(0), leitor.GetGuid(1), leitor.GetDecimal(2),
                leitor.GetString(3), leitor.GetFieldValue<DateTimeOffset>(4)));

        var temProxima = itens.Count > tamanho;
        if (temProxima) itens.RemoveAt(itens.Count - 1);

        return new PaginaHistoricoSql(itens, temProxima ? itens[^1].CriadoEm : null);
    }
}

// HistoricoRepositorioDynamo.cs — a mesma pergunta, respondida por chave em
// vez de plano de execução. O tempo de resposta não depende de quantos
// pedidos existem na tabela inteira: depende só do tamanho da PÁGINA.

public sealed class HistoricoRepositorioDynamo : IHistoricoRepositorioProjecao
{
    private readonly IAmazonDynamoDB _dynamo;
    private readonly string _tabela;

    public HistoricoRepositorioDynamo(IAmazonDynamoDB dynamo, IConfiguration config)
    {
        _dynamo = dynamo;
        _tabela = config["DynamoDb:TabelaHistorico"]!;
    }

    public async Task<PaginaHistoricoDynamo> BuscarAsync(
        Guid clienteId, string? cursor, int tamanho, CancellationToken ct)
    {
        var pedido = new QueryRequest
        {
            TableName = _tabela,
            KeyConditionExpression = "PK = :cliente AND begins_with(SK, :prefixo)",
            ExpressionAttributeValues = new Dictionary<string, AttributeValue>
            {
                [":cliente"] = new($"CLIENTE#{clienteId}"),
                [":prefixo"] = new("PEDIDO#"),
            },
            ScanIndexForward = false, // mais recente primeiro
            Limit = tamanho,
            // Padrão da tabela é leitura eventualmente consistente — metade
            // do custo da forte, e a projeção já tolera um atraso de
            // segundos. NÃO ligue ConsistentRead aqui: é o caminho de maior
            // volume, e dobrar o custo dele por padrão é o erro caro.
            ConsistentRead = false,
        };

        if (cursor is not null)
            pedido.ExclusiveStartKey = CursorCodec.Decodificar(cursor);

        var resposta = await _dynamo.QueryAsync(pedido, ct);
        var itens = resposta.Items.Select(MapearParaResumo).ToList();

        // Não existe "pular para a página 500": o próximo cursor só existe
        // se o DynamoDB devolveu LastEvaluatedKey. Paginação aqui é
        // sequencial — restrição de desenho, não limitação a contornar.
        var proximoCursor = resposta.LastEvaluatedKey is { Count: > 0 }
            ? CursorCodec.Codificar(resposta.LastEvaluatedKey)
            : null;

        return new PaginaHistoricoDynamo(itens, proximoCursor);
    }

    private static PedidoResumo MapearParaResumo(Dictionary<string, AttributeValue> item) => new(
        Guid.Parse(item["SK"].S.Split('#')[2]),
        Guid.Parse(item["loja_id"].S),
        decimal.Parse(item["total"].N, CultureInfo.InvariantCulture),
        item["status"].S,
        DateTimeOffset.Parse(item["SK"].S.Split('#')[1]));
}

// ProjetorOutbox.cs — lê a outbox commitada no Aurora e escreve a projeção
// no DynamoDB. A idempotência vem da CHAVE, não de um controle de estado
// separado: reprocessar o mesmo evento sobrescreve o mesmo item.

public sealed class ProjetorOutbox : BackgroundService
{
    private readonly NpgsqlDataSource _aurora;
    private readonly IAmazonDynamoDB _dynamo;
    private readonly string _tabela;
    private readonly ILogger<ProjetorOutbox> _log;

    protected override async Task ExecuteAsync(CancellationToken parar)
    {
        while (!parar.IsCancellationRequested)
        {
            var eventos = await BuscarPendentesAsync(lote: 100, parar);

            foreach (var evento in eventos)
            {
                await _dynamo.PutItemAsync(new PutItemRequest
                {
                    TableName = _tabela,
                    Item = new Dictionary<string, AttributeValue>
                    {
                        ["PK"] = new($"CLIENTE#{evento.ClienteId}"),
                        // A chave deriva do PEDIDO, não de quando o projetor
                        // rodou — reprocessar o mesmo pedido produz a MESMA
                        // chave, e o PutItem apenas sobrescreve com o mesmo
                        // conteúdo. É idempotência por construção.
                        ["SK"] = new($"PEDIDO#{evento.CriadoEm:O}#{evento.PedidoId}"),
                        ["loja_id"] = new(evento.LojaId.ToString()),
                        ["total"] = new AttributeValue
                            { N = evento.Total.ToString(CultureInfo.InvariantCulture) },
                        ["status"] = new(evento.Status),
                    },
                }, parar);

                // Marcar DEPOIS de projetar, nesta ordem. Inverter troca
                // "pode duplicar" por "pode perder" — e duplicar aqui é
                // inofensivo porque o PutItem é idempotente; perder não é.
                await MarcarProcessadaAsync(evento.Id, parar);
            }

            if (eventos.Count == 0)
                await Task.Delay(TimeSpan.FromSeconds(2), parar);
        }
    }

    private async Task<List<EventoOutbox>> BuscarPendentesAsync(int lote, CancellationToken ct)
    {
        // FOR UPDATE SKIP LOCKED permite rodar DUAS instâncias do projetor
        // sem que disputem a mesma linha — cada uma pula o que a outra já
        // travou, em vez de esperar.
        const string sql = """
            SELECT id, pedido_id, cliente_id, loja_id, total, status, criado_em
            FROM outbox_eventos
            WHERE processado_em IS NULL
            ORDER BY id
            LIMIT @lote
            FOR UPDATE SKIP LOCKED
            """;

        await using var conexao = await _aurora.OpenConnectionAsync(ct);
        await using var transacao = await conexao.BeginTransactionAsync(ct);
        await using var cmd = new NpgsqlCommand(sql, conexao, transacao);
        cmd.Parameters.AddWithValue("lote", lote);

        var eventos = new List<EventoOutbox>();
        await using var leitor = await cmd.ExecuteReaderAsync(ct);
        while (await leitor.ReadAsync(ct))
            eventos.Add(new EventoOutbox(
                leitor.GetInt64(0), leitor.GetGuid(1), leitor.GetGuid(2), leitor.GetGuid(3),
                leitor.GetDecimal(4), leitor.GetString(5), leitor.GetFieldValue<DateTimeOffset>(6)));

        await transacao.CommitAsync(ct); // libera os locks assim que a leitura termina
        return eventos;
    }

    private Task MarcarProcessadaAsync(long id, CancellationToken ct) =>
        _aurora.CreateCommand("UPDATE outbox_eventos SET processado_em = now() WHERE id = @id")
            .ExecuteNonQueryAsync(ct);
}

// RelatorioRepositorio.cs — a pergunta NOVA. Não existe chave para ela: é
// GROUP BY sobre milhões de linhas, no READER, com teto de tempo próprio.

public sealed class RelatorioRepositorio
{
    // Este NpgsqlDataSource aponta para o ENDPOINT DE LEITURA do Aurora —
    // outra connection string, outro pool, nunca o writer.
    private readonly NpgsqlDataSource _leitor;

    public RelatorioRepositorio(NpgsqlDataSource leitor) => _leitor = leitor;

    public async Task<IReadOnlyList<FaturamentoPorLoja>> FaturamentoAsync(
        DateOnly inicio, DateOnly fim, CancellationToken ct)
    {
        await using var conexao = await _leitor.OpenConnectionAsync(ct);

        // Teto próprio: uma consulta ruim aqui não consome conexão do
        // caminho do cliente, porque é outro pool — mas ainda pode ocupar
        // CPU do reader por tempo demais. O timeout é a segunda linha de
        // defesa, depois do isolamento de pool.
        await using (var ajuste = conexao.CreateCommand())
        {
            ajuste.CommandText = "SET statement_timeout = '30s'";
            await ajuste.ExecuteNonQueryAsync(ct);
        }

        const string sql = """
            SELECT loja_id, COUNT(*) AS pedidos, SUM(total) AS faturamento
            FROM pedidos
            WHERE criado_em >= @inicio AND criado_em < @fim
            GROUP BY loja_id
            ORDER BY faturamento DESC
            """;
        await using var consulta = new NpgsqlCommand(sql, conexao);
        consulta.Parameters.AddWithValue("inicio", inicio.ToDateTime(TimeOnly.MinValue));
        consulta.Parameters.AddWithValue("fim", fim.ToDateTime(TimeOnly.MinValue));

        var linhas = new List<FaturamentoPorLoja>();
        await using var leitor = await consulta.ExecuteReaderAsync(ct);
        while (await leitor.ReadAsync(ct))
            linhas.Add(new FaturamentoPorLoja(
                leitor.GetGuid(0), leitor.GetInt64(1), leitor.GetDecimal(2)));
        return linhas;
    }
}

#!/usr/bin/env bash
# medir-os-tres.sh — a MESMA carga contra os três caminhos, com o relatório
# rodando ao mesmo tempo. É a única forma honesta de comparar: medir cada
# banco isolado esconde justamente o efeito que este laboratório existe
# para mostrar.
set -euo pipefail

CLIENTE="3f2a1c10-8e3a-4a11-9c2e-000000000001"

medir() {
  local nome="$1" url="$2"
  echo "== $nome =="
  hey -z 30s -c 20 -q 10 "$url" | grep -E "50 % |95 % |99 % |Requests/sec"
}

# Dispara o relatório em paralelo — é ele que estressa o caminho compartilhado.
curl -s "$BASE_URL_RDS/relatorios/faturamento?inicio=2026-01-01&fim=2026-08-01" -o /dev/null &
RELATORIO_PID=$!

medir "RDS único (arquitetura mínima)"    "$BASE_URL_RDS/clientes/$CLIENTE/pedidos?tamanho=20"
medir "Aurora com reader isolado"          "$BASE_URL_AURORA/clientes/$CLIENTE/pedidos?tamanho=20"
medir "DynamoDB (projeção)"                "$BASE_URL_DYNAMO/clientes/$CLIENTE/pedidos?tamanho=20"

wait "$RELATORIO_PID"

# Nas medições de exemplo: RDS único p95 sobe de 22 ms para 340 ms com o
# relatório rodando; Aurora com reader isolado mantém 24 ms; DynamoDB mantém
# 11 ms e não varia com o volume da tabela nem com o relatório rodando ao
# lado, porque a Query nunca toca a instância do relatório.

# provas.sh — cinco medições; nenhuma conclusão vem de "parece mais rápido".
set -euo pipefail
CLIENTE="3f2a1c10-8e3a-4a11-9c2e-000000000001"

# ── Prova 1: o p95 do histórico não se move com o relatório rodando ─────────
# No Aurora com reader isolado e no DynamoDB, o p95 sob concorrência com o
# relatório deve ficar dentro de 20% do p95 isolado. No RDS único, ele sobe
# de ordem de grandeza — é o defeito que a arquitetura mínima expõe.
bash medir-os-tres.sh

# ── Prova 2: o custo de ligar ConsistentRead ────────────────────────────────
# Execute a mesma Query 1.000 vezes com ConsistentRead=false e depois com
# true, e compare ConsumedReadCapacityUnits no CloudWatch. Esperado: a soma
# com leitura forte é o DOBRO da soma com leitura eventual.
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=cadencia-historico-pedidos \
  --start-time "$(date -u -d '10 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Sum --output table

# ── Prova 3: o lag do reader do Aurora fica abaixo de 100 ms ────────────────
# AuroraReplicaLag é medido pela PRÓPRIA réplica; valor alto sinaliza reader
# sobrecarregado, não "banco lento" de forma genérica.
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name AuroraReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=ffv-lab-aurora-reader \
  --start-time "$(date -u -d '10 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Average Maximum --output table
# Esperado: média bem abaixo de 100 ms. Acima disso, o reader está recebendo
# carga além do que aguenta, e o "frescor" deixou de ser garantido.

# ── Prova 4: reprocessar o mesmo evento não duplica o item ──────────────────
# Rode o projetor duas vezes sobre o MESMO evento (sem marcar como
# processado entre as rodadas) e confirme que a contagem de itens não muda.
ANTES=$(aws dynamodb query --table-name cadencia-historico-pedidos \
  --key-condition-expression "PK = :c" \
  --expression-attribute-values "{\":c\":{\"S\":\"CLIENTE#$CLIENTE\"}}" \
  --select COUNT --query Count --output text)
# ... reexecuta o PutItem do mesmo evento aqui ...
DEPOIS=$(aws dynamodb query --table-name cadencia-historico-pedidos \
  --key-condition-expression "PK = :c" \
  --expression-attribute-values "{\":c\":{\"S\":\"CLIENTE#$CLIENTE\"}}" \
  --select COUNT --query Count --output text)
[ "$ANTES" = "$DEPOIS" ] && echo "OK: reprocessar não duplicou ($ANTES itens)" \
  || echo "FALHA DA PROVA: a contagem mudou de $ANTES para $DEPOIS"

# ── Prova 5: não existe "pular para a página 500" ────────────────────────────
# Tente pedir uma página sem ExclusiveStartKey e sem ter percorrido as
# anteriores: o resultado é sempre a PRIMEIRA página, nunca a que se "pulou"
# para. Confirma que a paginação é sequencial por desenho, não por limitação
# temporária do SDK.
curl -s "$BASE_URL_DYNAMO/clientes/$CLIENTE/pedidos?tamanho=20&pagina=500" | jq '.itens | length'
# Esperado: os 20 itens mais recentes — a mesma primeira página, porque não
# existe parâmetro de número de página, só cursor.

#!/usr/bin/env bash
# limpar.sh — o que o destroy não leva, nomeado.
set -euo pipefail
PROJETO="${PROJETO:?defina PROJETO}"

# 1. Deletion protection do Aurora e do DynamoDB tem de sair ANTES do
#    destroy, ou o Terraform falha no meio — e "falha no meio" com um
#    cluster já sem writer é o pior estado para diagnosticar.
aws rds modify-db-cluster --db-cluster-identifier "${PROJETO}-aurora" \
  --no-deletion-protection --apply-immediately
aws dynamodb update-table --table-name "${PROJETO}-historico-pedidos" \
  --no-deletion-protection-enabled 2>/dev/null || true

terraform destroy -auto-approve

# 2. SNAPSHOT FINAL DO AURORA: por decisão deste módulo, ele NÃO é apagado
#    pelo destroy (skip_final_snapshot = false). Ele cobra armazenamento
#    até ser removido à mão.
aws rds describe-db-cluster-snapshots \
  --query "DBClusterSnapshots[?contains(DBClusterSnapshotIdentifier, '${PROJETO}')].DBClusterSnapshotIdentifier" \
  --output table
# aws rds delete-db-cluster-snapshot --db-cluster-snapshot-identifier <nome>  # descomente quando decidir apagar

# 3. TABELA DO DYNAMODB: se deletion_protection_enabled estava ligado e o
#    passo 1 não rodou, o destroy falha e a tabela sobrevive cobrando por
#    armazenamento e, se ainda houver tráfego de teste, por requisição.
aws dynamodb describe-table --table-name "${PROJETO}-historico-pedidos" \
  --query "Table.TableStatus" --output text 2>/dev/null || echo "tabela já removida"

# 4. Endpoint de gateway do DynamoDB: sai com o destroy (é recurso Terraform
#    comum), mas confira — ele não aparece como "cobra parado" porque
#    endpoint de gateway não tem cobrança por hora, ao contrário do de
#    interface.

# 5. Prova final: nada com a tag do projeto de pé.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values="$PROJETO" \
  --query "ResourceTagMappingList[].ResourceARN" --output table