Lab 07 — O banco sob carga: réplica, Multi-AZ e o pool

-- Pergunta 1: a carga cabe na maquina? DBLoadRelativeToNumVCPUs no
-- CloudWatch acima de 1 significa mais sessoes ativas do que nucleos.
-- Na Cadencia esse numero era 0,9 — a fila NAO era o problema.

-- Pergunta 2: qual consulta consome o tempo? Ordene por tempo TOTAL.
SELECT substring(query, 1, 60) AS consulta, calls,
       round(100 * total_exec_time / sum(total_exec_time) OVER (), 1) AS pct
  FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-- Na Cadencia: um unico item respondia por 78%. Com esse numero na mao, a
-- discussao de arquitetura ainda nao tinha comecado — e ja tinha resposta.

// O que a assinatura de eventos entrega quando a troca ocorre. Assinar o
// EVENTO e mais confiavel que vigiar metrica: a troca e um fato discreto, e
// metrica so mostra o rastro dela.
{
  "Source": "aws.rds",
  "detail-type": "RDS DB Instance Event",
  "resources": ["arn:aws:rds:us-east-1:111122223333:db:ffv-lab-primario"],
  "detail": {
    "SourceIdentifier": "ffv-lab-primario",
    "SourceType": "DB_INSTANCE",
    "EventCategories": ["failover"],
    "Date": "2026-08-07T14:22:31.618Z",
    // A razao aparece no log de eventos, e "user requested" e a do ENSAIO.
    // Em incidente real ela diz se foi patch de sistema, host insalubre,
    // perda de rede, primario ocupado ou falha de volume.
    "Message": "Multi-AZ instance failover completed"
  }
}

-- diagnostico.sql — a ordem importa: medir, depois decidir.
-- Rode como usuario com rds_superuser. `pg_stat_statements` ja vem carregado no
-- shared_preload_libraries do grupo de parametros padrao do RDS para PostgreSQL,
-- entao criar a extensao basta e nao exige reinicio.
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 1. QUEM consome o banco. Ordenar por tempo TOTAL, e nao por tempo medio: uma
--    consulta de 2 s chamada 40 mil vezes por hora domina uma de 30 s chamada
--    tres vezes por dia, e e a primeira que derruba o pico.
SELECT substring(query, 1, 90) AS consulta,
       calls,
       round(total_exec_time)             AS tempo_total_ms,
       round(mean_exec_time, 2)           AS media_ms,
       round(100 * total_exec_time / sum(total_exec_time) OVER (), 1) AS pct
  FROM pg_stat_statements
 WHERE query NOT LIKE '%pg_stat%'
 ORDER BY total_exec_time DESC
 LIMIT 10;
-- Na Cadencia: a consulta do painel respondia por 78% do tempo total de execucao.
-- Um unico item. Antes de discutir arquitetura, isso ja e o diagnostico.

-- 2. O PLANO da consulta campea. ANALYZE executa de verdade e mostra o tempo
--    real; BUFFERS mostra quantos blocos foram lidos, que e o que explica a CPU.
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF)
SELECT p.id, p.total, p.criado_em
  FROM pedido p
 WHERE p.loja_id = 314
   AND p.criado_em >= now() - interval '7 days'
 ORDER BY p.criado_em DESC
 LIMIT 50;
-- ANTES:  Seq Scan on pedido  (actual time=0.03..2180.4 rows=1284 loops=1)
--         Buffers: shared hit=1204 read=68312
--         Execution Time: 2180.912 ms
-- Ler 68 mil blocos do disco a cada abertura de painel e o custo, e ele nao cai
-- com mais nucleos: cai com menos blocos lidos.

-- 3. O indice. CONCURRENTLY nao trava escrita na tabela, e por isso pode entrar
--    em producao no meio do dia. Ele custa mais tempo para construir e nao pode
--    rodar dentro de transacao.
CREATE INDEX CONCURRENTLY IF NOT EXISTS ix_pedido_loja_data
    ON pedido (loja_id, criado_em DESC);
-- A ordem das colunas nao e estetica: `loja_id` primeiro porque e igualdade, e
-- `criado_em` depois porque e faixa. Invertido, o indice serve mal os dois.

-- DEPOIS:  Index Scan using ix_pedido_loja_data  (actual time=0.02..3.31 rows=1284)
--          Buffers: shared hit=41 read=6
--          Execution Time: 3.412 ms
-- 2180 ms -> 3,4 ms, e a CPU do primario caiu de 98% para 24% no mesmo pico.

-- 4. QUANTAS sessoes existem de fato, e em que estado. `idle` e sessao guardada
--    no pool sem uso; `idle in transaction` e o sintoma que mais dói, porque a
--    sessao segura recursos sem estar fazendo nada.
SELECT state, count(*) AS sessoes, max(now() - state_change) AS mais_antiga
  FROM pg_stat_activity
 WHERE datname = current_database()
 GROUP BY state
 ORDER BY sessoes DESC;

SHOW max_connections;              -- o teto real desta instancia
SHOW superuser_reserved_connections; -- vagas que a sua aplicacao nao pode usar

-- 5. O papel restrito a consulta. Criado no PRIMARIO: em replica fisica os
--    papeis chegam pela replicacao, e tentar criar na replica falha.
CREATE ROLE app_leitura LOGIN PASSWORD :'senha_leitura';
GRANT CONNECT ON DATABASE pedidos TO app_leitura;
GRANT USAGE ON SCHEMA public TO app_leitura;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_leitura;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_leitura;
-- Com isto, uma gravacao que escapar para o caminho de leitura falha na BORDA do
-- privilegio, com mensagem clara, em vez de falhar por acaso na replica.
ALTER ROLE app_leitura SET default_transaction_read_only = on;

# banco.tf — a replica de leitura, os parametros que tornam o diagnostico
# possivel e os alarmes que separam consulta ruim de falta de maquina.

# O primario vem do L01 e nao e redeclarado aqui. Este laboratorio acrescenta a
# replica, os parametros e a observacao.
variable "primario_id" {
  type        = string
  description = "Identificador da instancia primaria criada no L01"
}

variable "projeto" {
  type    = string
  default = "ffv-lab"
}

# ── Grupo de parametros: o que torna o diagnostico possivel ─────────────────
#
# Sem estes tres, o incidente deste laboratorio e indiagnosticavel depois do
# fato: voce ve a CPU alta e nao sabe qual consulta a causou.
resource "aws_db_parameter_group" "pedidos" {
  name   = "${var.projeto}-pg16"
  family = "postgres16"

  # `pg_stat_statements` ja vem no shared_preload_libraries do grupo padrao do
  # RDS. Declaramos aqui de propósito: grupo customizado NAO herda a lista do
  # padrao, e esquecer esta linha desliga a extensao em silencio.
  parameter {
    name         = "shared_preload_libraries"
    value        = "pg_stat_statements"
    apply_method = "pending-reboot"
  }

  # Consulta acima de 1 s vai para o log. O valor e uma decisao de volume: em 1 s
  # o log registra o que importa; em 100 ms ele registra tudo e ninguem le.
  parameter {
    name         = "log_min_duration_statement"
    value        = "1000"
    apply_method = "immediate"
  }

  # `log_lock_waits` mostra espera por travamento, que e a segunda causa de
  # latencia alta com CPU baixa — o oposto do caso deste laboratorio.
  parameter {
    name         = "log_lock_waits"
    value        = "1"
    apply_method = "immediate"
  }
}

# ── A replica de leitura ────────────────────────────────────────────────────
#
# `replicate_source_db` e o que faz deste recurso uma replica, e nao um banco
# novo. Replicacao ASSINCRONA: existe uma janela em que o dado esta confirmado no
# primario e ainda nao chegou aqui. Essa janela e o assunto da secao de provas.
resource "aws_db_instance" "leitura" {
  identifier          = "${var.projeto}-leitura"
  replicate_source_db = var.primario_id

  # Classe MENOR que a do primario, de propósito: a replica atende relatorio, nao
  # gravacao. Se ela ficar pequena demais, o atraso de replicacao cresce — e o
  # alarme de atraso e justamente o instrumento que diz isso.
  instance_class = "db.m6g.large"

  # A replica fica em uma TERCEIRA AZ. Nao na do standby: concentrar as duas
  # copias na mesma AZ desfaz metade do beneficio de ter duas.
  availability_zone = var.az_leitura

  # A replica NAO precisa de Multi-AZ para este caso de uso. Ligar aqui dobraria
  # o custo dela para proteger uma carga de relatorio que tolera indisponibilidade
  # de minutos. Em L58, quando a replica virar caminho de recuperacao, muda.
  multi_az = false

  parameter_group_name   = aws_db_parameter_group.pedidos.name
  vpc_security_group_ids = [var.sg_banco_id]
  publicly_accessible    = false
  storage_encrypted      = true
  kms_key_id             = var.kms_key_arn

  # Performance Insights e o que permite atribuir carga a evento de espera. Sete
  # dias de retencao ficam na camada sem custo adicional; retencao longa cobra.
  performance_insights_enabled          = true
  performance_insights_retention_period = 7

  # Log do PostgreSQL no CloudWatch. Cria um grupo de logs que NAO desaparece com
  # o destroy da instancia — esta na secao de limpeza por isso.
  enabled_cloudwatch_logs_exports = ["postgresql"]

  # Replica nao aceita `skip_final_snapshot = false`: nao existe snapshot final de
  # replica. Manter explicito evita a surpresa no destroy.
  skip_final_snapshot = true
  apply_immediately   = true

  tags = {
    Projeto = var.projeto
    Papel   = "leitura"
    Lab     = "L07"
  }
}

# ── Alarmes: cada um responde a UMA pergunta ────────────────────────────────

# "A frota esta perto do teto de sessoes?" O limiar e 70% do `max_connections`
# desta classe, e nao um numero redondo: em 8 GiB o teto fica em cerca de 900.
resource "aws_cloudwatch_metric_alarm" "sessoes" {
  alarm_name          = "${var.projeto}-sessoes-perto-do-teto"
  namespace           = "AWS/RDS"
  metric_name         = "DatabaseConnections"
  statistic           = "Maximum"
  period              = 60
  evaluation_periods  = 3
  threshold           = 630
  comparison_operator = "GreaterThanThreshold"
  dimensions          = { DBInstanceIdentifier = var.primario_id }
  alarm_description   = "630 = 70% de ~900. Acima disto, o operador tambem perde o acesso."
  alarm_actions       = [var.topico_alarme_arn]
}

# "A carga e maior do que a maquina?" DBLoadRelativeToNumVCPUs acima de 1 significa
# mais sessoes ativas do que nucleos: a fila e real. Abaixo de 1 com latencia alta
# aponta para outra coisa — travamento, rede, disco.
resource "aws_cloudwatch_metric_alarm" "carga_relativa" {
  alarm_name          = "${var.projeto}-carga-acima-dos-nucleos"
  namespace           = "AWS/RDS"
  metric_name         = "DBLoadRelativeToNumVCPUs"
  statistic           = "Average"
  period              = 60
  evaluation_periods  = 5
  threshold           = 1
  comparison_operator = "GreaterThanThreshold"
  dimensions          = { DBInstanceIdentifier = var.primario_id }
  alarm_description   = "Publicada somente quando ha carga; exige Performance Insights ligado."
  alarm_actions       = [var.topico_alarme_arn]
}

# "A replica esta longe do primario?" 30 s da folga de mais de uma ordem de
# grandeza sobre o pior caso medido (1,9 s no lote noturno) e ainda fica abaixo
# do artefato documentado de 5 minutos em base ociosa.
resource "aws_cloudwatch_metric_alarm" "atraso_replica" {
  alarm_name          = "${var.projeto}-replica-atrasada"
  namespace           = "AWS/RDS"
  metric_name         = "ReplicaLag"
  statistic           = "Maximum"
  period              = 60
  evaluation_periods  = 3
  threshold           = 30
  comparison_operator = "GreaterThanThreshold"
  dimensions          = { DBInstanceIdentifier = aws_db_instance.leitura.identifier }
  alarm_description   = "Sem escrita no primario, o atraso reportado sobe ate 5 min por projeto."
  alarm_actions       = [var.topico_alarme_arn]
}

# "Trocou de AZ?" Assinar a categoria de evento em vez de vigiar metrica: a troca
# e um EVENTO, e metrica so mostra o rastro dela.
resource "aws_db_event_subscription" "failover" {
  name             = "${var.projeto}-eventos-de-troca"
  sns_topic        = var.topico_alarme_arn
  source_type      = "db-instance"
  source_ids       = [var.primario_id, aws_db_instance.leitura.identifier]
  event_categories = ["failover", "failure", "availability", "maintenance"]
}

# proxy.tf — a porta das sessoes de escrita.
#
# LIMITE DOCUMENTADO, e ele decide o desenho: para instancias do RDS em
# configuracao de replicacao, o proxy pode ser associado APENAS a instancia de
# escrita, nunca a uma replica de leitura. Ou seja: o proxy resolve o problema de
# sessao do lado da GRAVACAO, e o roteamento de leitura continua sendo trabalho
# da aplicacao. Quem espera que o proxy "distribua leitura" desenha errado.

resource "aws_db_proxy" "escrita" {
  name                   = "${var.projeto}-proxy-escrita"
  engine_family          = "POSTGRESQL"
  role_arn               = aws_iam_role.proxy.arn
  vpc_subnet_ids         = var.subnets_privadas
  vpc_security_group_ids = [var.sg_proxy_id]

  # TLS obrigatorio entre aplicacao e proxy. Sem isto, a credencial atravessa a
  # VPC em claro — e "e rede interna" nao e argumento desde que existe conta
  # comprometida por movimento lateral.
  require_tls = true

  # 1800 s e generoso e existe para nao cortar sessao de manutencao. Em aplicacao
  # web, sessao ociosa por 30 min e sintoma, nao caso de uso.
  idle_client_timeout = 1800

  auth {
    auth_scheme = "SECRETS"
    iam_auth    = "DISABLED"
    secret_arn  = var.segredo_escrita_arn
  }

  tags = { Projeto = var.projeto, Lab = "L07" }
}

resource "aws_db_proxy_default_target_group" "escrita" {
  db_proxy_name = aws_db_proxy.escrita.name

  connection_pool_config {
    # O proxy pode usar ate 60% do `max_connections` do banco. O resto fica para
    # migracao, rotina agendada, ferramenta de BI e o terminal do operador. Deixar
    # em 100 entrega o banco inteiro a um unico consumidor.
    max_connections_percent = 60

    # Sessoes ociosas que o proxy mantem prontas. Baixo demais e cada surto paga
    # o custo de abrir conexao; alto demais desperdicia vaga do banco.
    max_idle_connections_percent = 15

    # Quanto tempo o cliente espera na fila antes de receber erro. E aqui que o
    # surto vira ESPERA MEDIDA em vez de recusa de vaga: o comportamento que a
    # documentacao descreve como enfileirar ou limitar.
    connection_borrow_timeout = 5

    # Toda sessao do proxy nasce com este ajuste. Cinturao de seguranca: se uma
    # gravacao chegar pelo caminho errado, ela falha com mensagem clara.
    init_query = "SET statement_timeout = '15s'"
  }
}

resource "aws_db_proxy_target" "primario" {
  db_proxy_name          = aws_db_proxy.escrita.name
  target_group_name      = aws_db_proxy_default_target_group.escrita.name
  db_instance_identifier = var.primario_id
}

# ── IAM do proxy: menor privilegio, sem um unico curinga ────────────────────
resource "aws_iam_role" "proxy" {
  name = "${var.projeto}-proxy-escrita"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Action    = "sts:AssumeRole"
      Principal = { Service = "rds.amazonaws.com" }
    }]
  })
}

data "aws_iam_policy_document" "proxy" {
  statement {
    sid       = "LerApenasOSegredoDesteBanco"
    actions   = ["secretsmanager:GetSecretValue"]
    resources = [var.segredo_escrita_arn]
  }

  statement {
    sid       = "DecifrarApenasViaSecretsManager"
    actions   = ["kms:Decrypt"]
    resources = [var.kms_key_arn]

    # A condicao estreita o que o ARN sozinho nao estreita: a chave so pode ser
    # usada quando a chamada vem do Secrets Manager. Sem ela, o papel poderia
    # decifrar qualquer coisa cifrada com essa chave.
    condition {
      test     = "StringEquals"
      variable = "kms:ViaService"
      values   = ["secretsmanager.${var.regiao}.amazonaws.com"]
    }
  }
}

resource "aws_iam_role_policy" "proxy" {
  role   = aws_iam_role.proxy.id
  policy = data.aws_iam_policy_document.proxy.json
}

# ── IAM da task: o unico "*" deste laboratorio, e a frase que o justifica ───
data "aws_iam_policy_document" "task_metricas" {
  statement {
    sid     = "PublicarMetricaDePoolNoNamespaceDoProjeto"
    actions = ["cloudwatch:PutMetricData"]

    # `cloudwatch:PutMetricData` NAO suporta permissao no nivel de recurso: nao
    # existe ARN de metrica. O curinga aqui nao e preguica, e a unica forma
    # aceita pela acao — e o estreitamento vai para a condicao abaixo, que limita
    # a UM namespace. Sem a condicao, a task poderia escrever em qualquer metrica
    # da conta, inclusive sobrescrevendo painel de outro time.
    resources = ["*"]

    condition {
      test     = "StringEquals"
      variable = "cloudwatch:namespace"
      values   = ["FFV/Banco"]
    }
  }
}

// Banco.cs — dois destinos, dois pools, e a decisao de rota por operacao.
//
// A decisao central deste arquivo: o destino NAO cabe no texto de conexao.
// Um texto de conexao vale para o PROCESSO; a tolerancia a atraso de replicacao
// e por OPERACAO. Quem escreve a consulta sabe se ela tolera; nada abaixo dela
// sabe. Por isso a rota e um argumento com nome, e nao uma configuracao.

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;
using Npgsql;
using System.Diagnostics.Metrics;

public static class Banco
{
    // ── 1. Os dois pools ────────────────────────────────────────────────────
    //
    // NpgsqlDataSource E o dono do pool. Criar um por requisicao recria o pool e
    // anula todo o ganho — e e o erro mais comum de quem vem de conexao avulsa.
    // Por isso: um por destino, vivendo o tempo da aplicacao.
    static NpgsqlDataSource Fonte(string conexao, int maximo, string papel)
    {
        var c = new NpgsqlDataSourceBuilder(conexao);
        c.ConnectionStringBuilder.MaxPoolSize = maximo;
        c.ConnectionStringBuilder.MinPoolSize = 2;

        // O padrao do Npgsql e 100 por processo, e e ele que produz a conta
        // `tasks x pool`. Aqui os valores sao DERIVADOS do teto do banco:
        // 6 tasks x (10 + 40) = 300 sessoes de pior caso contra ~900 disponiveis,
        // deixando folga para migracao, rotina agendada e o operador.

        // `Timeout` (padrao 15 s) mede a espera para OBTER a conexao, incluindo a
        // fila do pool. 5 s no caminho de leitura porque relatorio que espera 15 s
        // por uma vaga ja perdeu o usuario: falhar rapido e mais honesto.
        c.ConnectionStringBuilder.Timeout = papel == "leitura" ? 5 : 10;

        // `ConnectionLifetime` e 3600 s por padrao desde a versao 9.0. Reduzir
        // importa por um motivo especifico deste laboratorio: uma sessao aberta
        // aponta para o endereco que o nome do endpoint resolvia NAQUELE momento,
        // e reciclar encurta o rastro de uma troca de zona.
        c.ConnectionStringBuilder.ConnectionLifetime = 900;

        // `ConnectionIdleLifetime` fica no padrao de 300 s: sessao ociosa no pool
        // ocupa vaga no banco, e vaga ocupada por nada e a mais cara de todas.
        return c.Build();
    }

    public static void AdicionarBanco(this WebApplicationBuilder builder)
    {
        var escrita = Fonte(builder.Configuration["Banco:Escrita"]!, 10, "escrita");
        var leitura = Fonte(builder.Configuration["Banco:Leitura"]!, 40, "leitura");

        builder.Services.AddSingleton(new MedidorDeEspera());
        builder.Services.AddScoped<MarcaDeEscrita>();
        builder.Services.AddSingleton<Degradacao>();
        builder.Services.AddScoped<Roteador>();

        // O interceptador que MARCA a escrita e resolvido do provedor da
        // REQUISICAO, e nao de dentro do EF. Isto importa: `DbContext.GetService`
        // consulta o provedor INTERNO do EF Core, onde um servico com escopo de
        // requisicao nao existe — a marca sairia sempre falsa, em silencio.
        builder.Services.AddScoped<MarcadorDeEscrita>();

        builder.Services.AddDbContext<PedidosDb>((sp, o) => o
            .UseNpgsql(escrita)
            .AddInterceptors(sp.GetRequiredService<MarcadorDeEscrita>(),
                             sp.GetRequiredService<MedidorDeEspera>()));

        builder.Services.AddDbContext<PedidosLeituraDb>((sp, o) => o
            .UseNpgsql(leitura)
            .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking)
            .AddInterceptors(sp.GetRequiredService<MedidorDeEspera>()));

        // ── Saude: o que a task NAO pode viver sem ──────────────────────────
        //
        // A prontidao toca o PRIMARIO e nao toca a replica. Se ela dependesse da
        // replica, uma falha do caminho de relatorio marcaria as seis tasks como
        // inaptas, o balanceador as removeria, e uma degradacao PARCIAL viraria
        // indisponibilidade TOTAL — com o agravante de as tasks novas nascerem
        // igualmente inaptas. Prontidao verifica o que impede a task de
        // trabalhar, nao tudo com que ela conversa.
        builder.Services.AddHealthChecks()
            .AddNpgSql(escrita, name: "primario", tags: ["ready"])
            .AddNpgSql(leitura, name: "replica", tags: ["degradado"]);
    }

    public static void MapearSaude(this WebApplication app)
    {
        app.MapHealthChecks("/health/live", new() { Predicate = _ => false });
        app.MapHealthChecks("/health/ready",
            new() { Predicate = c => c.Tags.Contains("ready") });
        // Esta rota NAO entra no health check do balanceador: ela alimenta painel
        // e alarme, e responder 503 aqui nao deve remover task nenhuma.
        app.MapHealthChecks("/health/degradado",
            new() { Predicate = c => c.Tags.Contains("degradado") });
    }
}

// ── 2. Dois contextos sobre o MESMO modelo ──────────────────────────────────
//
// A subclasse da ao EF Core dois contextos distintos sem duplicar mapeamento:
// `OnModelCreating` e herdado. O de leitura nasce sem rastreamento, porque
// rastrear entidade que nunca sera salva e memoria gasta por nada.
public class PedidosDb(DbContextOptions<PedidosDb> opcoes) : DbContext(opcoes)
{
    public DbSet<Pedido> Pedidos => Set<Pedido>();
    protected override void OnModelCreating(ModelBuilder m) { /* mapeamento */ }
}

public sealed class PedidosLeituraDb(DbContextOptions<PedidosLeituraDb> opcoes)
    : DbContext(opcoes)
{
    public DbSet<Pedido> Pedidos => Set<Pedido>();
    // Reaproveita a MESMA configuracao do contexto de escrita, chamando o
    // mapeamento compartilhado. Duas classes, um modelo, nenhuma duplicacao.
    protected override void OnModelCreating(ModelBuilder m) => Mapeamento.Aplicar(m);
}

// ── 3. A cerca de leitura-apos-escrita ──────────────────────────────────────
//
// Escopo por requisicao. Assim que qualquer gravacao e confirmada, toda leitura
// SEGUINTE daquela requisicao volta ao primario. Resolve o caso comum — gravar e
// conferir na mesma tela — sem exigir coordenacao por posicao no registro de
// escrita. NAO cobre gravar numa aba e ler em outra: sao requisicoes diferentes,
// e para esse caso existe a cerca por posicao, que custa uma consulta a mais.
public sealed class MarcaDeEscrita
{
    public bool Houve { get; set; }
}

public sealed class MarcadorDeEscrita(MarcaDeEscrita marca) : SaveChangesInterceptor
{
    public override ValueTask<int> SavedChangesAsync(
        SaveChangesCompletedEventData dados, int resultado,
        CancellationToken ct = default)
    {
        marca.Houve = true;
        return base.SavedChangesAsync(dados, resultado, ct);
    }
}

// O roteador. Uma unica pergunta, e ela e explicita na assinatura.
public sealed class Roteador(
    PedidosDb primario, PedidosLeituraDb replica,
    MarcaDeEscrita marca, Degradacao degradacao)
{
    public bool UsaReplica(bool toleraAtraso) =>
        toleraAtraso && !marca.Houve && !degradacao.ReplicaSuspeita;

    public PedidosDb Escrita => primario;

    public IQueryable<Pedido> Pedidos(bool toleraAtraso) =>
        UsaReplica(toleraAtraso) ? replica.Pedidos : primario.Pedidos;
}

// ── 4. A porta de retorno, com limite ───────────────────────────────────────
//
// Se a replica cai e TODA a leitura volta ao primario, voce reproduziu o
// incidente original com uma peca a mais. Por isso o retorno e contado e
// alarmado: voltar ao primario e medida temporaria, nunca regime.
public sealed class Degradacao
{
    static readonly Meter Medidor = new("FFV.Banco");
    static readonly Counter<long> Retornos =
        Medidor.CreateCounter<long>("leitura.retorno_ao_primario");

    DateTimeOffset _suspeitaAte = DateTimeOffset.MinValue;

    public bool ReplicaSuspeita => DateTimeOffset.UtcNow < _suspeitaAte;

    public void Registrar(Exception e)
    {
        Retornos.Add(1, new KeyValuePair<string, object?>("motivo", e.GetType().Name));
        // Janela curta e deliberada: 30 s reabre o caminho de leitura para
        // reavaliacao em vez de deixar o retorno virar permanente por esquecimento.
        _suspeitaAte = DateTimeOffset.UtcNow.AddSeconds(30);
    }
}

// ── 5. A metrica que o banco NAO tem como dar ───────────────────────────────
//
// O banco sabe quantas sessoes existem. Ele nao sabe quanto tempo a SUA
// aplicacao esperou por uma vaga no pool — e e esse numero que distingue dois
// sintomas identicos na tela: latencia alta com CPU do banco baixa. Se a espera
// e alta e o banco esta folgado, o pool e pequeno. Se a espera e baixa e a
// latencia e alta, o banco e o gargalo. As correcoes sao opostas.
public sealed class MedidorDeEspera : DbConnectionInterceptor
{
    static readonly Meter Medidor = new("FFV.Banco");
    static readonly Histogram<double> Espera =
        Medidor.CreateHistogram<double>("pool.espera_ms", unit: "ms");

    public override Task ConnectionOpenedAsync(
        System.Data.Common.DbConnection conexao,
        ConnectionEndEventData dados, CancellationToken ct = default)
    {
        // `Duration` cobre a obtencao da conexao. Com provedor agrupado, isso
        // inclui a espera na fila do pool: p99 acima de 50 ms aqui e pool
        // pequeno, e nao banco lento.
        Espera.Record(dados.Duration.TotalMilliseconds,
                      new KeyValuePair<string, object?>("destino", conexao.DataSource));
        return Task.CompletedTask;
    }
}

// PedidosEndpoints.cs — como a decisao aparece para quem escreve consulta.

// Gravacao: sempre no primario. O interceptador marca a requisicao, e daqui para
// a frente toda leitura DELA volta ao primario mesmo se pedir a replica.
app.MapPost("/api/pedidos", async (NovoPedido entrada, Roteador rota) =>
{
    var pedido = Pedido.De(entrada);
    rota.Escrita.Pedidos.Add(pedido);
    await rota.Escrita.SaveChangesAsync();
    return Results.Created($"/api/pedidos/{pedido.Id}", pedido.Id);
});

// Conferencia imediata: NAO tolera atraso, e isso e declarado. Ainda que a marca
// de escrita cobrisse este caso, a declaracao sobrevive a uma refatoracao que
// mova o codigo para outra requisicao — e a marca nao sobrevive.
app.MapGet("/api/pedidos/{id}", async (long id, Roteador rota) =>
    await rota.Pedidos(toleraAtraso: false).FirstOrDefaultAsync(p => p.Id == id)
        is { } p ? Results.Ok(p) : Results.NotFound());

// Painel: tolera atraso. E o caminho que o indice deste laboratorio acelerou e
// que a replica passou a isolar da gravacao.
app.MapGet("/api/paineis/loja/{lojaId}",
    async (int lojaId, Roteador rota, Degradacao deg) =>
{
    var desde = DateTime.UtcNow.AddDays(-7);
    try
    {
        return Results.Ok(await rota.Pedidos(toleraAtraso: true)
            .Where(p => p.LojaId == lojaId && p.CriadoEm >= desde)
            .OrderByDescending(p => p.CriadoEm)
            .Take(50)
            .ToListAsync());
    }
    catch (NpgsqlException e)
    {
        // A replica falhou. Registra e cai para o primario, com JANELA: se o
        // retorno virasse regime silencioso, o primario voltaria a receber tudo e
        // o incidente original se reproduziria com uma peca a mais na conta.
        deg.Registrar(e);
        return Results.Ok(await rota.Pedidos(toleraAtraso: false)
            .Where(p => p.LojaId == lojaId && p.CriadoEm >= desde)
            .OrderByDescending(p => p.CriadoEm)
            .Take(50)
            .ToListAsync());
    }
});

// Relatorio de 90 dias: o requisito que de fato justificou a replica. Agregacao
// pesada por natureza, que nenhum indice torna leve, e que competia por nucleos
// com a gravacao de pedido. O ganho aqui e ISOLAMENTO, nao velocidade.
app.MapGet("/api/relatorios/mensal", async (Roteador rota) =>
{
    var desde = DateTime.UtcNow.AddDays(-90);
    return Results.Ok(await rota.Pedidos(toleraAtraso: true)
        .Where(p => p.CriadoEm >= desde)
        .GroupBy(p => new { p.LojaId, Mes = p.CriadoEm.Month })
        .Select(g => new { g.Key.LojaId, g.Key.Mes, Total = g.Sum(x => x.Total) })
        .ToListAsync());
});

// ── A alternativa de menos linhas, e por que ela nao substitui isto ─────────
//
// O Npgsql aceita varios hosts num texto de conexao e escolhe por
// `Target Session Attributes`, com os valores `any`, `primary`, `standby`,
// `prefer-primary`, `prefer-standby`, `read-write` e `read-only`. Ele detecta o
// papel consultando `pg_is_in_recovery()` e `default_transaction_read_only`, e
// revisa a cada `Host Recheck Seconds` (padrao 10). E menos codigo:
//
//   Host=primario.rds,replica.rds;Target Session Attributes=prefer-standby
//
// O que essa forma NAO consegue expressar e justamente a decisao deste modulo:
// "esta leitura precisa do primario porque segue uma gravacao". O atributo vale
// para a CONEXAO, e a tolerancia a atraso e por OPERACAO. Use os multiplos hosts
// para o que ele resolve bem — sobreviver a troca de papel sem trocar
// configuracao — e mantenha a decisao de rota no codigo.
//
// E NAO ligue `Load Balance Hosts=true` com primario e replica na mesma lista
// junto de `Target Session Attributes=Any`: cada abertura comeca num ponto
// diferente da lista, e uma gravacao vai cair na replica de tempo em tempo,
// falhando com erro de transacao somente para consulta numa fracao das
// requisicoes. O sintoma e intermitente, que e o pior tipo.

# provas.sh — cinco medicoes. Nenhuma conclusao vem de "parece melhor".

# ── PROVA 1: o standby nao atende leitura, e nao existe endereco para tentar ──
# Nao ha endpoint de standby para listar. A ausencia E a prova.
aws rds describe-db-instances --db-instance-identifier ffv-lab-primario \
  --query "DBInstances[0].{Endpoint:Endpoint.Address,MultiAZ:MultiAZ,\
AZ:AvailabilityZone,SecundariaAZ:SecondaryAvailabilityZone}"
# APROVA se: MultiAZ=true, com AZ e SecundariaAZ diferentes, e UM unico Endpoint.
# REPROVA se voce encontrar um segundo endereco: entao nao e Multi-AZ com standby
# unico, e sim um cluster Multi-AZ — que tem dois leitores que ATENDEM consulta,
# endpoint de leitura e replicacao semissincrona. Sao produtos diferentes.

psql "$ESCRITA" -Atc "SELECT pg_is_in_recovery();"   # esperado: f (sempre)
psql "$LEITURA" -Atc "SELECT pg_is_in_recovery();"   # esperado: t
psql "$LEITURA" -Atc "INSERT INTO pedido (loja_id, total) VALUES (1, 10);" || true
# APROVA com: ERROR: cannot execute INSERT in a read-only transaction (SQLSTATE 25006)

# ── PROVA 2: o indice, medido antes e depois ─────────────────────────────────
psql "$ESCRITA" -c "EXPLAIN (ANALYZE, BUFFERS, COSTS OFF) $CONSULTA_DO_PAINEL"
# APROVA se: o plano deixa de conter "Seq Scan on pedido" e o Execution Time cai
# de tres digitos de milissegundo para um. Medido na Cadencia: 2180,9 ms -> 3,4 ms,
# com blocos lidos caindo de 68.312 para 6. A CPU do primario foi de 98% a 24%.
# REPROVA se o plano continua em Seq Scan: quase sempre a ordem das colunas do
# indice esta invertida, ou a consulta aplica funcao sobre a coluna filtrada.

# ── PROVA 3: o teto de sessoes e tasks x pool ────────────────────────────────
psql "$ESCRITA" -Atc "SHOW max_connections;"                    # ~900 em 8 GiB
psql "$ESCRITA" -Atc "SELECT count(*) FROM pg_stat_activity;"
TASKS=$(aws ecs describe-services --cluster ffv-lab --services ffv-lab-api \
          --query "services[0].runningCount" --output text)
echo "pior caso = $TASKS x (10 + 40) = $(( TASKS * 50 )) sessoes"
# APROVA se: o pior caso calculado fica abaixo de 70% do max_connections.
# Na Cadencia: 6 x 50 = 300 contra ~900, e antes do ajuste 6 x 100 = 600.
# Para VER o teto agir, suba tasks e mantenha carga; o erro que aparece e
# "FATAL: remaining connection slots are reserved for non-replication superuser
# connections" (SQLSTATE 53300) — e ele atinge o operador tambem.

# ── PROVA 4: o atraso de replicacao existe e e mensuravel ────────────────────
ID=$(psql "$ESCRITA" -Atc \
  "INSERT INTO pedido (loja_id, total) VALUES (314, 99) RETURNING id;")
psql "$LEITURA" -Atc "SELECT count(*) FROM pedido WHERE id = $ID;"
# APROVA com 0 em alguma das tentativas sob carga: e a demonstracao de "gravei e
# nao vejo". Repita 200 vezes e conte. Na Cadencia, com o lote noturno rodando,
# 7 de 200 leituras imediatas nao encontraram a linha.
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=ffv-lab-leitura \
  --start-time "$(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Maximum Average
# Na Cadencia: p50 de 12 ms, p95 de 240 ms, maximo de 1,9 s no lote noturno.

# ── PROVA 5: o failover, ensaiado e cronometrado nos DOIS lados ──────────────
( while true; do
    inicio=$(date +%s%3N)
    if psql "$ESCRITA" -Atc "INSERT INTO sonda (t) VALUES (now());" >/dev/null 2>&1
      then echo "$(date +%T.%3N) ok $(( $(date +%s%3N) - inicio ))ms"
      else echo "$(date +%T.%3N) FALHA"
    fi
    sleep 0.2
  done ) > sonda-escrita.log &
SONDA=$!

aws rds reboot-db-instance --db-instance-identifier ffv-lab-primario --force-failover
aws rds describe-events --source-identifier ffv-lab-primario \
  --source-type db-instance --duration 10 \
  --query "Events[].{Q:Date,M:Message}" --output table
sleep 180; kill $SONDA
grep -c FALHA sonda-escrita.log
# APROVA se: existe uma janela contigua de FALHA e ela termina sozinha, sem
# reiniciar task nenhuma. Medido no ensaio de exemplo: 47 s no total, com a
# resolucao do nome mudando por volta de 34 s e os 13 s restantes gastos
# esvaziando sessoes do pool que apontavam para o endereco antigo.
#
# ATENCAO ao interpretar: a documentacao da AWS diz que a troca "tipicamente"
# leva de 60 a 120 s, e nao promete numero. Os 47 s deste ensaio sao de UMA
# instancia pequena com transacao curta em voo, e nao valem como referencia para
# a sua. O que vale como metodo e a DECOMPOSICAO: mede-se a troca e mede-se o
# esvaziamento do pool separadamente, porque eles tem donos diferentes.

-- lag.sql — medir atraso de replicacao dos dois lados.

-- NA REPLICA: quanto tempo faz que a ultima transacao replicada foi aplicada.
SELECT pg_is_in_recovery()                                  AS e_replica,
       now() - pg_last_xact_replay_timestamp()              AS atraso,
       pg_last_wal_replay_lsn()                             AS posicao_aplicada;
-- Na Cadencia, sob carga de pico: p50 de 12 ms, p95 de 240 ms, e 1,9 s durante
-- o lote noturno de fechamento. O alarme ficou em 30 s, com folga de uma ordem
-- de grandeza sobre o pior caso observado.

-- ARMADILHA DOCUMENTADA: sem transacao no primario, a replica reporta atraso de
-- ATE CINCO MINUTOS. O calculo e `now() - ultima_transacao_confirmada`, e o RDS
-- troca o segmento do registro de escrita a cada 5 minutos — so entao o numero
-- cai. Alarme de atraso configurado em 60 s dispara toda madrugada em ambiente
-- ocioso, e o time aprende a ignorar o alarme. Combine com carga de escrita.

-- NO PRIMARIO: quem esta conectado replicando, e o quanto cada um esta atras.
SELECT client_addr, state, sync_state,
       pg_current_wal_lsn() - replay_lsn AS bytes_atras
  FROM pg_stat_replication;
-- `sync_state` distingue as duas replicacoes deste laboratorio: o standby do
-- Multi-AZ e sincrono e nao aparece aqui como sessao sua; a replica de leitura
-- aparece como assincrona. Sao mecanismos diferentes, com garantias diferentes.

-- A CERCA RIGOROSA de leitura-apos-escrita, para quando marcar a requisicao nao
-- basta. No primario, apos o commit:
SELECT pg_current_wal_lsn() AS marca;
-- Na replica, antes de responder:
SELECT pg_last_wal_replay_lsn() >= '0/1A2B3C4D'::pg_lsn AS ja_chegou;
-- Se `false`, espere ou leia do primario. Isto custa uma ida a mais e resolve o
-- caso que a marcacao por requisicao nao cobre: usuario que grava numa aba e le
-- em outra, em requisicoes diferentes.

# FALHA 1 — apague o indice e veja a CPU voltar.
psql "$ESCRITA" -c "DROP INDEX ix_pedido_loja_data;"
# Sintoma: p95 do painel volta a segundos; CPU sobe; sessoes seguem POUCAS.
# Onde olhar: pg_stat_statements ordenado por tempo total. O item campeao
# reaparece no topo com quase todo o tempo, e DBLoadRelativeToNumVCPUs
# continua abaixo de 1 — o que confirma consulta, e nao concorrencia.
# Correcao: recriar com CONCURRENTLY. E a licao: monitore a EXISTENCIA dos
# indices criticos, porque migracao mal escrita apaga indice em silencio.

# FALHA 2 — mande TODA a leitura para a replica, inclusive a que segue
# gravacao. Basta trocar o argumento na rota de conferencia.
#   rota.Pedidos(toleraAtraso: true)   // era false
# Sintoma: o cliente grava um pedido, e a tela seguinte diz que ele nao
# existe. Intermitente, e mais frequente sob carga — o pior tipo, porque
# nao reproduz na maquina do desenvolvedor, onde nao ha atraso.
# Onde olhar: correlacione o horario da reclamacao com ReplicaLag. Se o
# atraso subiu naquele minuto, o diagnostico esta fechado.
# Correcao: `toleraAtraso: false` na conferencia, e a marca por requisicao
# como rede de seguranca para quem esquecer.

# FALHA 3 — devolva os pools ao padrao e escale as tasks.
aws ecs update-service --cluster ffv-lab --service ffv-lab-api --desired-count 20
# Com MaxPoolSize em 100 nos dois destinos: 20 x 200 = 4.000 sessoes possiveis
# contra ~900. Sintoma: "FATAL: remaining connection slots are reserved for
# non-replication superuser connections" (SQLSTATE 53300).
# O detalhe que dói: o operador tambem nao conecta. Voce perde o acesso ao
# banco exatamente quando precisa dele para diagnosticar.
psql "$ESCRITA" -Atc "SELECT count(*) FROM pg_stat_activity;"  # pode falhar
# Correcao imediata: reduzir desired-count. Correcao real: pool derivado do
# teto, e porta na frente para que escalar nao toque o parametro do banco.

# 1. Derrube o que o Terraform administra neste laboratorio.
terraform destroy -auto-approve

# 2. REPLICA DE LEITURA: confirme que sumiu. Ela cobra como instancia cheia,
#    24 horas por dia, e o nome "replica" faz a linha parecer pequena.
aws rds describe-db-instances \
  --query "DBInstances[?DBInstanceIdentifier=='ffv-lab-leitura'].DBInstanceStatus" \
  --output text
aws rds delete-db-instance --db-instance-identifier ffv-lab-leitura \
  --skip-final-snapshot 2>/dev/null || true

# 3. PORTA DE CONEXAO: cobra por hora e por capacidade da instancia atendida.
aws rds describe-db-proxies --query "DBProxies[].DBProxyName" --output table
aws rds delete-db-proxy --db-proxy-name ffv-lab-proxy-escrita 2>/dev/null || true

# 4. SNAPSHOT: o destroy do PRIMARIO cria snapshot final quando
#    skip_final_snapshot e falso — e snapshot cobra por GB-mes para sempre.
#    Liste os manuais: os automaticos morrem com a instancia, os manuais nao.
aws rds describe-db-snapshots --snapshot-type manual \
  --query "DBSnapshots[].{Nome:DBSnapshotIdentifier,GB:AllocatedStorage}" \
  --output table
# Apague com delete-db-snapshot o que voce nao vai restaurar no L10.

# 5. GRUPO DE LOGS do PostgreSQL: criado pela exportacao de log, com ciclo
#    proprio. Sobrevive a instancia e continua cobrando ingestao retida.
aws logs describe-log-groups --log-group-name-prefix /aws/rds/instance/ffv-lab \
  --query "logGroups[].{Nome:logGroupName,Retencao:retentionInDays}" --output table
aws logs delete-log-group \
  --log-group-name /aws/rds/instance/ffv-lab-leitura/postgresql 2>/dev/null || true

# 6. GRUPO DE PARAMETROS e ASSINATURA DE EVENTOS: nao cobram, mas ficam. Um
#    grupo de parametros em uso nao pode ser apagado, o que e uma pista util.
aws rds delete-db-parameter-group --db-parameter-group-name ffv-lab-pg16 \
  2>/dev/null || true
aws rds delete-event-subscription --subscription-name ffv-lab-eventos-de-troca \
  2>/dev/null || true

# 7. SEGREDO do papel de leitura: fica em exclusao agendada, por padrao, e
#    ocupa o nome durante a janela. Isso quebra o proximo terraform apply.
aws secretsmanager delete-secret --secret-id ffv-lab-banco-leitura \
  --recovery-window-in-days 7 2>/dev/null || true

# 8. O que veio do L01 e continua cobrando por hora: o PRIMARIO em Multi-AZ,
#    o balanceador, o endpoint de VPC e o Elastic IP do NAT, se existirem.
#    Se voce nao vai seguir para o L10, rode a limpeza do L01 tambem.
aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].PublicIp" --output table

# 9. Prova final: nada com a etiqueta do laboratorio de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Lab,Values=L07 \
  --query "ResourceTagMappingList[].ResourceARN" --output table