Lab 32 — Síncrono ou assíncrono entre serviços

0,999 × 0,999 × 0,999 × 0,999 ≈ 0,996006  →  99,6006%

Indisponibilidade de um único serviço:  0,1000% do tempo
Indisponibilidade da cadeia de quatro:  0,3994% do tempo
                                         (quase 4× mais)

Em minutos por mês (30 dias = 43.200 min):
  um serviço só:    ~43 min de indisponibilidade
  cadeia de quatro: ~173 min de indisponibilidade

Caminho síncrono (Pedidos, Catálogo, Pagamento):
  0,999 × 0,999 × 0,999 ≈ 0,997003  →  99,7003%
  indisponibilidade: 0,2997% do tempo (~129 min/mês)

Contra a corrente original de 4 elos (99,6006%, ~173 min/mês):
  ganho de ~44 minutos de disponibilidade por mês
  SEM adicionar redundância nova — só removendo um fator da multiplicação

Notificações: fora da conta de disponibilidade do pedido. Sua própria
disponibilidade agora é medida como atraso de fila, não como causa de erro 5xx.

{
  "source": "cadencia.pedidos",
  "detail-type": "PedidoCriado",
  "detail": {
    "pedidoId": "b3f1c2a4-9e21-4a3d-8f2a-1234567890ab",
    "clienteId": "c-9",
    "email": "cliente@exemplo.com",
    "preco": 129.90,
    "autorizacaoId": "auth-77213"
  }
}

# service-connect.tf — o timeout de cada salto, explícito, e crescendo para fora
#
# Amazon ECS Service Connect usa Cloud Map por baixo, mas o que importa aqui e o
# TIMEOUT: cada servico declara o teto que promete a quem o chama. Sem isto
# configurado, o padrao do Service Connect e generoso demais para esta cadeia
# (idleTimeout de 5 min em HTTP) — ele nao quebra nada sozinho, mas tambem nao
# implementa a regra dos timeouts decrescentes: e voce quem tem de configura-la.

resource "aws_service_discovery_http_namespace" "cadencia" {
  name = "cadencia.local"
}

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

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_http_namespace.cadencia.arn

    service {
      port_name      = "http"
      discovery_name  = "notificacoes"
      client_alias {
        port     = 8080
        dns_name = "notificacoes"
      }
      # O elo mais interno da corrente original: 3 s e desiste. Nao ha ninguem
      # depois dele para esperar, entao este e o UNICO valor que nao precisa
      # ser maior que o de um vizinho.
      timeout {
        per_request_timeout_seconds = 3
      }
    }
  }

  network_configuration {
    subnets         = aws_subnet.privada[*].id
    security_groups = [aws_security_group.task.id]
  }
}

resource "aws_ecs_service" "pagamento" {
  name            = "cadencia-pagamento"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.pagamento.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_http_namespace.cadencia.arn

    service {
      port_name     = "http"
      discovery_name = "pagamento"
      client_alias {
        port     = 8080
        dns_name = "pagamento"
      }
      # Promete 8 s a quem o chama: cobre o proprio processamento mais os ate
      # 5 s que o cliente HTTP interno espera de Notificacoes (configurado no
      # C#, nao aqui — Service Connect nao sabe quem o SEU servico chama).
      timeout {
        per_request_timeout_seconds = 8
      }
    }
  }

  network_configuration {
    subnets         = aws_subnet.privada[*].id
    security_groups = [aws_security_group.task.id]
  }
}

resource "aws_ecs_service" "catalogo" {
  name            = "cadencia-catalogo"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.catalogo.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_http_namespace.cadencia.arn

    service {
      port_name     = "http"
      discovery_name = "catalogo"
      client_alias {
        port     = 8080
        dns_name = "catalogo"
      }
      # 13 s: cobre o proprio trabalho mais os ate 10 s que o cliente HTTP
      # interno espera de Pagamento.
      timeout {
        per_request_timeout_seconds = 13
      }
    }
  }

  network_configuration {
    subnets         = aws_subnet.privada[*].id
    security_groups = [aws_security_group.task.id]
  }
}

# Pedidos NAO precisa de service_connect_configuration para SER chamado — ele so
# CHAMA os outros tres. O timeout que ele pratica ao chamar Catalogo (16 s) e
# Pagamento (8 s, mesmo valor que Pagamento promete) vive no HttpClient do C#,
# porque e ali que a decisao de "quanto esperar" realmente atua.
resource "aws_ecs_service" "pedidos" {
  name            = "cadencia-pedidos"
  cluster         = aws_ecs_cluster.principal.id
  task_definition = aws_ecs_task_definition.pedidos.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_http_namespace.cadencia.arn
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.pedidos.arn
    container_name    = "pedidos"
    container_port    = 8080
  }

  network_configuration {
    subnets         = aws_subnet.privada[*].id
    security_groups = [aws_security_group.task.id]
  }
}

// PedidosService.cs — dois chamados irmãos, não uma corrente; e o timeout
// prometido por cada vizinho vira o timeout que este serviço PRATICA.

public sealed class PedidosService
{
    private readonly HttpClient _catalogo;
    private readonly HttpClient _pagamento;
    private readonly AmazonEventBridgeClient _eventos;
    private readonly ILogger<PedidosService> _log;

    public PedidosService(
        IHttpClientFactory factory, AmazonEventBridgeClient eventos, ILogger<PedidosService> log)
    {
        // Cada HttpClient tem o timeout do VIZINHO que ele chama, nao um valor
        // generico repetido tres vezes. E a regra dos timeouts decrescentes
        // escrita em codigo: se Catalogo promete 13 s, este client espera 16 s
        // — sempre MAIOR, nunca igual, para nao desistir no instante em que a
        // resposta esta a caminho.
        _catalogo = factory.CreateClient("catalogo");
        _catalogo.Timeout = TimeSpan.FromSeconds(16);
        _catalogo.BaseAddress = new Uri("http://catalogo:8080");

        _pagamento = factory.CreateClient("pagamento");
        _pagamento.Timeout = TimeSpan.FromSeconds(9); // Pagamento promete 8 s; 9 s de margem
        _pagamento.BaseAddress = new Uri("http://pagamento:8080");

        _eventos = eventos;
        _log = log;
    }

    public async Task<ResultadoPedido> CriarAsync(NovoPedido novo, CancellationToken ct)
    {
        // 1) Catalogo primeiro: sem item valido e preco confirmado nao ha o que
        //    cobrar. Isto e sequencial por NECESSIDADE de dado (o preco entra na
        //    chamada de Pagamento), nao por aninhamento de servico — a diferenca
        //    e que Catalogo nunca soube que Pagamento existe.
        var item = await _catalogo.GetFromJsonAsync<ItemCatalogo>(
            $"/produtos/{novo.ProdutoId}", ct)
            ?? throw new ItemIndisponivelException(novo.ProdutoId);

        // 2) Pagamento em seguida, com o preco que Catalogo confirmou.
        var autorizacao = await _pagamento.PostAsJsonAsync(
            "/autorizacoes", new { novo.ClienteId, item.Preco }, ct);
        autorizacao.EnsureSuccessStatusCode();
        var resultado = await autorizacao.Content.ReadFromJsonAsync<Autorizacao>(ct)
            ?? throw new AutorizacaoInvalidaException();

        var pedidoId = Guid.NewGuid();

        // 3) So AGORA, com os dois "sim" que o cliente precisa, o pedido existe.
        //    O evento e disparado e NAO bloqueia a resposta: PutEventsAsync
        //    confirma em milissegundos que a AWS aceitou o evento, nao que
        //    alguem o processou.
        await _eventos.PutEventsAsync(new PutEventsRequest
        {
            Entries =
            {
                new PutEventsRequestEntry
                {
                    Source       = "cadencia.pedidos",
                    DetailType   = "PedidoCriado",
                    EventBusName = "cadencia-eventos",
                    Detail = JsonSerializer.Serialize(new
                    {
                        pedidoId,
                        novo.ClienteId,
                        Email = novo.Email,
                        item.Preco,
                        AutorizacaoId = resultado.Id,
                    }),
                },
            },
        }, ct);

        return new ResultadoPedido(pedidoId, item.Preco, resultado.Id);
    }
}

# eventos.tf — o caminho que NAO bloqueia a resposta ao cliente

resource "aws_cloudwatch_event_bus" "cadencia" {
  name = "cadencia-eventos"
}

resource "aws_sqs_queue" "notificacao_pedido_dlq" {
  name                      = "cadencia-notificacao-pedido-dlq"
  message_retention_seconds = 1209600 # 14 dias — o teto do proprio SQS
}

resource "aws_sqs_queue" "notificacao_pedido" {
  name = "cadencia-notificacao-pedido"

  # Padrao da AWS e 30 s; o processamento (SES + gravacao de idempotencia) leva
  # perto de 1 s no exemplo medido — 30 s fica confortavel e NAO foi reduzido,
  # porque reduzir aqui nao devolve nada: quem espera este relogio e o proprio
  # SQS, nao um cliente HTTP.
  visibility_timeout_seconds = 30

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.notificacao_pedido_dlq.arn
    # Depois de 5 tentativas sem exclusao bem-sucedida da mensagem, ela sai da
    # fila principal — e para de competir por processamento com pedidos novos.
    maxReceiveCount = 5
  })
}

resource "aws_cloudwatch_event_rule" "roteia_pedido_criado" {
  name           = "roteia-pedido-criado"
  event_bus_name = aws_cloudwatch_event_bus.cadencia.name

  event_pattern = jsonencode({
    source      = ["cadencia.pedidos"]
    detail-type = ["PedidoCriado"]
  })
}

resource "aws_cloudwatch_event_target" "para_fila_notificacao" {
  rule           = aws_cloudwatch_event_rule.roteia_pedido_criado.name
  event_bus_name = aws_cloudwatch_event_bus.cadencia.name
  arn            = aws_sqs_queue.notificacao_pedido.arn
}

# So o EventBridge pode publicar nesta fila — nao qualquer principal com
# sqs:SendMessage. Sem isto, um chamador poderia fabricar um "PedidoCriado" e
# jogar direto na fila, contornando Pedidos e a autorizacao que o precede.
resource "aws_sqs_queue_policy" "so_eventbridge_publica" {
  queue_url = aws_sqs_queue.notificacao_pedido.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "events.amazonaws.com" }
      Action    = "sqs:SendMessage"
      Resource  = aws_sqs_queue.notificacao_pedido.arn
      Condition = {
        ArnEquals = { "aws:SourceArn" = aws_cloudwatch_event_rule.roteia_pedido_criado.arn }
      }
    }]
  })
}

# Idempotencia do consumidor: guarda o pedidoId ja processado, com TTL — nao
# para consultar depois, so para a escrita condicional decidir "e novo ou e
# reentrega" em uma unica chamada atomica.
resource "aws_dynamodb_table" "notificacoes_processadas" {
  name         = "cadencia-notificacoes-processadas"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "pedido_id"

  attribute {
    name = "pedido_id"
    type = "S"
  }

  ttl {
    attribute_name = "expira_em"
    enabled        = true
  }
}

data "aws_iam_policy_document" "notificacoes_consome_fila" {
  statement {
    effect = "Allow"
    actions = [
      "sqs:ReceiveMessage",
      "sqs:DeleteMessage",
      "sqs:GetQueueAttributes",
    ]
    # Restrito a ESTA fila — nao ha motivo para o consumidor de notificacao
    # enxergar qualquer outra fila da conta.
    resources = [aws_sqs_queue.notificacao_pedido.arn]
  }
  statement {
    effect    = "Allow"
    actions   = ["dynamodb:PutItem", "dynamodb:GetItem"]
    resources = [aws_dynamodb_table.notificacoes_processadas.arn]
  }
}

# Alarme sobre o sintoma que a corrente sincrona antiga escondia: mensagem
# envelhecendo na fila e mensagem parada na DLQ.
resource "aws_cloudwatch_metric_alarm" "fila_envelhecendo" {
  alarm_name          = "cadencia-notificacao-fila-envelhecendo"
  namespace           = "AWS/SQS"
  metric_name         = "ApproximateAgeOfOldestMessage"
  dimensions          = { QueueName = aws_sqs_queue.notificacao_pedido.name }
  statistic           = "Maximum"
  period              = 60
  evaluation_periods  = 3
  threshold           = 300 # 5 min sem consumir e sintoma, nao normalidade
  comparison_operator = "GreaterThanThreshold"
  alarm_actions       = [aws_sns_topic.alertas.arn]
}

// NotificacaoWorker.cs — consumidor assíncrono, idempotente por construção

public sealed class NotificacaoWorker : BackgroundService
{
    private readonly IAmazonSQS _sqs;
    private readonly IAmazonDynamoDB _idempotencia;
    private readonly IAmazonSimpleEmailServiceV2 _ses;
    private readonly string _filaUrl;
    private readonly ILogger<NotificacaoWorker> _log;

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        while (!ct.IsCancellationRequested)
        {
            // Long polling de 20 s: reduz chamadas vazias sem exigir nenhum
            // ajuste no visibility timeout da fila, que e um relogio separado.
            var lote = await _sqs.ReceiveMessageAsync(new ReceiveMessageRequest
            {
                QueueUrl            = _filaUrl,
                MaxNumberOfMessages = 10,
                WaitTimeSeconds     = 20,
            }, ct);

            foreach (var msg in lote.Messages)
            {
                var evento = JsonSerializer.Deserialize<PedidoCriadoEvento>(msg.Body)!;

                // A escrita condicional E a checagem de idempotencia: se o item
                // ja existe, PutItem falha com ConditionalCheckFailedException,
                // e isto significa "ja processei este pedido antes" — SQS e
                // at-least-once, entao reentrega e o caso normal, nao a excecao.
                try
                {
                    await _idempotencia.PutItemAsync(new PutItemRequest
                    {
                        TableName = "cadencia-notificacoes-processadas",
                        Item = new Dictionary<string, AttributeValue>
                        {
                            ["pedido_id"] = new() { S = evento.PedidoId.ToString() },
                            ["expira_em"] = new() { N = DateTimeOffset.UtcNow.AddDays(7).ToUnixTimeSeconds().ToString() },
                        },
                        ConditionExpression = "attribute_not_exists(pedido_id)",
                    }, ct);
                }
                catch (ConditionalCheckFailedException)
                {
                    _log.LogInformation("pedido {Id} ja notificado; reentrega ignorada", evento.PedidoId);
                    await _sqs.DeleteMessageAsync(_filaUrl, msg.ReceiptHandle, ct);
                    continue;
                }

                await _ses.SendEmailAsync(MontarEmailConfirmacao(evento), ct);

                // So apaga DEPOIS do envio confirmado. Se o processo cair entre
                // o PutItem e o DeleteMessage, a mensagem volta a ficar visivel
                // apos o visibility timeout — e a proxima tentativa cai no
                // ConditionalCheckFailedException acima e so limpa a fila, sem
                // reenviar o e-mail. E esse o motivo de a ordem importar aqui.
                await _sqs.DeleteMessageAsync(_filaUrl, msg.ReceiptHandle, ct);
            }
        }
    }
}

# provas.sh — cinco medições; a disponibilidade composta se prova, não se afirma

PROJETO=cadencia; REGIAO=us-east-1
URL="https://$(terraform output -raw dominio)/api/pedidos"

# ── Prova 1: a linha de base da corrente ORIGINAL (4 elos) ───────────────────
# 2.000 requisições contra a corrente síncrona aninhada, sem matar nada.
for i in $(seq 1 2000); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "$URL" \
    -d '{"produtoId":"p-42","clienteId":"c-9"}'
done | sort | uniq -c
# Esperado: por volta de 99,5–99,6% em 200/201 — perto do 0,999⁴ ≈ 99,60%
# previsto. Ruído normal de rede explica a diferença de décimos.

# ── Prova 2: derrube SÓ Pagamento, e meça quem mais falha ────────────────────
aws ecs update-service --cluster "$PROJETO" --service cadencia-pagamento \
  --desired-count 0 --region "$REGIAO"
sleep 20  # tempo para as tasks de Pagamento saírem de RUNNING

for i in $(seq 1 600); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "$URL" \
    -d '{"produtoId":"p-42","clienteId":"c-9"}'
done | sort | uniq -c
# Esperado no desenho ORIGINAL (corrente aninhada): perto de 100% de erro —
# toda requisição que chega em Catálogo falha, porque ele depende de Pagamento.

aws ecs describe-services --cluster "$PROJETO" \
  --services cadencia-pedidos cadencia-catalogo --region "$REGIAO" \
  --query 'services[].{nome:serviceName,tasksSaudaveis:runningCount}'
# Esperado: Pedidos e Catálogo com runningCount = desiredCount, os dois "de pé"
# — é a prova de que a falha reportada não é deles.

aws ecs update-service --cluster "$PROJETO" --service cadencia-pagamento \
  --desired-count 2 --region "$REGIAO"

# ── Prova 3: o mesmo teste, no desenho de PRODUÇÃO (achatado) ────────────────
# Repita a prova 2 depois de aplicar o desenho achatado. Catálogo não conhece
# mais Pagamento, então derrubar Pagamento não deveria mais afetar a chamada a
# Catálogo — só a chamada direta de Pedidos a Pagamento.
# Esperado: a taxa de erro cai para perto de 1/3 da cadeia (só o hop de
# Pagamento falha), não mais toda a cadeia.

# ── Prova 4: Notificações cai por 5 minutos; o pedido continua sendo criado ──
aws ecs update-service --cluster "$PROJETO" --service cadencia-notificacoes \
  --desired-count 0 --region "$REGIAO"
for i in $(seq 1 300); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "$URL" \
    -d '{"produtoId":"p-42","clienteId":"c-9"}'
  sleep 1
done | sort | uniq -c
# Esperado: 100% em 201, mesmo com Notificações inteiramente fora do ar — é o
# critério de aceite do desenho de produção.
aws sqs get-queue-attributes --queue-url "$(terraform output -raw fila_notificacao_url)" \
  --attribute-names ApproximateNumberOfMessages
# Esperado: a contagem cresce ~300 durante a janela, provando que nada se perdeu.
aws ecs update-service --cluster "$PROJETO" --service cadencia-notificacoes \
  --desired-count 2 --region "$REGIAO"
# Depois de religar, a fila deve drenar para perto de zero em minutos.

# ── Prova 5: mensagem-veneno vai para a DLQ sem travar as boas ───────────────
aws sqs send-message --queue-url "$(terraform output -raw fila_notificacao_url)" \
  --message-body '{"pedidoId": "nao-e-um-guid-valido"}'
# Aguarde 5 tentativas de reentrega (5 × visibility timeout de 30 s ≈ 2,5 min).
sleep 160
aws sqs get-queue-attributes \
  --queue-url "$(terraform output -raw fila_notificacao_dlq_url)" \
  --attribute-names ApproximateNumberOfMessages
# Esperado: 1 mensagem na DLQ, e nenhum efeito nas mensagens legítimas
# processadas na mesma janela.

# A ordem importa: remova o que consome antes do que produz, para não deixar
# mensagem presa apontando para um alvo que já não existe.
terraform destroy \
  -target=aws_ecs_service.notificacoes \
  -target=aws_cloudwatch_event_target.para_fila_notificacao \
  -target=aws_cloudwatch_event_rule.roteia_pedido_criado

terraform destroy   # o restante: Pedidos, Catálogo, Pagamento, fila, DLQ, tabela