Do pedido
ao pagamento.

O pedido continua. O pagamento ganha seu tempo. [01]

No Cap 01, construímos uma API: um programa que recebe requisições HTTP, aplica regras e guarda pedidos no PostgreSQL, um banco de dados que roda dentro de um container Docker. Até aqui, tudo acontecia dentro de um único programa: o pedido chegava, a regra rodava, o banco salvava, a resposta voltava.

Agora vamos separar dois trabalhos que parecem um só: receber a solicitação de pagamento e processar o pagamento. Eles vão rodar em programas diferentes, em momentos diferentes. Para ligá-los, usaremos uma fila de mensagens.

O Pedido 4711 é nosso apelido no desenho. Na API, cada pedido recebe um UUID (identificador universal único): um código como 89e83d74-29b8-4a52-aaf0-2f33877c9f99. Você usará o ID retornado pelo seu projeto.

Hoje usamos pagamentos simulados: APROVAR e RECUSAR são cenários controlados de aula. Não há banco financeiro, cartão, Pix ou dinheiro real envolvido.

Uma tarde, uma história verificável [02]

A tarde tem quatro partes. Primeiro entendemos por que filas existem e como o RabbitMQ entrega mensagens — com desenhos e fluxos animados. Depois colocamos a mão no painel, sem código. Só então o agente constrói os dois serviços, e terminamos provocando falhas de propósito.

Cada etapa prática segue entender → prever → orientar o agente → executar → conferir. O prompt funciona em Claude Code, Codex CLI ou outro agente capaz de trabalhar no projeto. A decisão continua com você.

📓 Abrir caderno livre · Baixar collection do Insomnia · Guia de execução e recuperação

Coloque o agente para ler enquanto conversamos [03]

Um diagnóstico leva alguns minutos: o agente precisa ler arquivos e rodar testes. Em vez de esperar parado, dispare o prompt agora e siga para a teoria. Quando voltar ao terminal, a resposta estará pronta para ser revisada.

Queremos um diagnóstico com evidências: versão do Java, banco, endpoints e testes. Uma lista de arquivos não prova que a aplicação funciona; um teste passando, sim.

[CONTEXTO] Vou continuar a API de Pedidos do Cap 01 com pagamentos simulados por RabbitMQ.
[TAREFA] Sem criar nem editar arquivos, leia AGENTS.md, CLAUDE.md e as specs relevantes. Identifique endpoints, status do pedido, configuração do Postgres e Docker Compose existente. Execute os testes unitários pelo Maven Wrapper.
[LIMITES] Não instale dependências nem reinicie ou remova containers. Não presuma que concluí as tarefas anteriores.
[ACEITE] Separe funcionando com prova, falhando e ainda ausente. Mostre como criar e consultar um pedido de 2 cafés a 18.90.
[PAUSA] Proponha o menor ponto de retomada e aguarde meu OK antes de editar.

[CONTEXTO] Meu projeto de Pedidos ainda não está em nenhum repositório remoto. Criei um repositório vazio no GitHub: COLE-AQUI-O-LINK
[TAREFA] Mostre git status e git remote -v. Se a pasta ainda não for um repositório Git, inicialize com a branch main. Revise ou crie o .gitignore para Java, Maven e IntelliJ (target/, .idea/, *.iml, .env, logs). Mostre a lista exata de arquivos que entrariam no primeiro commit.
[LIMITES] Nunca inclua tokens, senhas pessoais ou arquivos .env. Não use force push e não reescreva histórico. Se o push pedir autenticação, pare e me explique o que fazer: eu mesmo faço o login (gh auth login ou chave SSH).
[ACEITE] Após meu OK na lista: commit inicial em português, remote origin apontando para o link, push da main com upstream. Mostre git log --oneline -3, git remote -v e o endereço da branch main no GitHub.
[PAUSA] Aguarde meu OK antes do commit e antes do push.

Esperar na ligação ou deixar uma comanda? [04]

Avance o fluxo abaixo um passo por vez. Antes de cada clique, diga em voz alta o que espera ver na faixa de cima e na de baixo.

Na nossa API, o HTTP continua tendo resposta. O que muda é seu significado: 202 Accepted é um código HTTP que quer dizer “aceito para processamento, ainda não terminei”. Para saber o resultado, a cliente consulta de novo (GET /pedidos/{id}). Não vamos manter a requisição HTTP aberta esperando o pagamento.

Regra de bolso: códigos 2xx são sucesso, 4xx são problema no que o cliente mandou, 5xx são problema do lado do servidor.

A conta da dependência [05]

“Assíncrono é mais robusto” é uma frase fácil de repetir e difícil de justificar. Vamos fazer a conta.

O que viaja dentro de uma mensagem [06]

Falamos em “mensagem” o tempo todo. Mas o que é, fisicamente, a coisa que sai de Pedidos e chega em Pagamentos?

1. Pedidos monta um objeto Solicitacao com os dados do pedido.
2. Jackson transforma o objeto em JSON, e o JSON em bytes.
3. Os bytes viajam dentro da mensagem até a fila.
4. Pagamentos recebe os bytes e Jackson reconstrói um objeto Solicitacao — uma cópia, em outro programa.

public record Solicitacao(int versao, String solicitacaoId, String pedidoId,
                          BigDecimal valor, String cenario) { }

Um record é uma classe Java curta, só com dados: o compilador gera construtor e métodos de leitura. Repare no campo versao. Os dois serviços são implantados separadamente; um dia, Pedidos pode mandar um formato novo enquanto Pagamentos ainda roda o antigo. O número da versão permite ao consumidor reconhecer o formato e recusar o que não entende, em vez de interpretar errado.

Comando, evento e consulta [07]

Nem toda mensagem tem a mesma intenção. Dar o nome certo evita desenhos confusos — e diz quem é dono de cada decisão.

Seis peças, uma função cada [08]

Um broker de mensagens (intermediário de mensagens) é um programa servidor especializado em receber, guardar e entregar mensagens entre outros programas. Usaremos o RabbitMQ, um broker de código aberto muito usado com Java. Ele fala o protocolo AMQP (Advanced Message Queuing Protocol) — as regras de conversa entre aplicação e broker, como o HTTP é para navegador e servidor.

Duas palavras completam o endereço. Uma routing key (chave de roteamento) é um texto enviado junto com a publicação, como pagamento.solicitar. Um binding (ligação) é uma regra configurada no broker: “desta exchange, mande para esta fila as mensagens com tal chave”.

Na volta, os papéis se invertem: Pagamentos vira produtor do resultado (na exchange pagamentos.eventos) e Pedidos vira consumidor (da fila pedidos.resultados). Produtor e consumidor são papéis numa conversa, não tipos de programa.

A exchange roteia; não guarda [09]

Fila: Ready, Unacked e ack [10]

Uma fila precisa de um lugar para existir [11]

O RabbitMQ é outro programa. Vamos executá-lo em um container, como já fizemos com o Postgres. A imagem com sufixo management inclui o painel visual de administração. Um healthcheck é uma verificação automática de saúde: indica se o serviço está pronto para responder. Um volume guarda os dados do broker fora do container, para sobreviverem a reinícios.

[CONTEXTO] A API já usa Postgres no Docker. Quero adicionar RabbitMQ à infraestrutura atual.
[TAREFA] Inspecione o Compose e proponha adicionar RabbitMQ 4.1-management com volume nomeado, healthcheck, usuário local aula e senha didática aula-local. Publique 5672 para as aplicações e 15672 para o painel, somente em 127.0.0.1. Confira conflitos de porta.
[LIMITES] Preserve o Postgres e seus volumes. Não use down -v, não apague dados e não crie outro Postgres por conveniência. Não altere Java nesta etapa. Credenciais são apenas para ambiente local.
[ACEITE] Após meu OK, suba somente o necessário. Mostre healthcheck saudável e painel acessível. Explique a diferença entre 5672 (mensagens) e 15672 (painel).
[PAUSA] Mostre o plano e aguarde meu OK.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

Streams, que aparecem no nome da aba, são outro recurso do RabbitMQ (um registro de mensagens que pode ser relido). Não usaremos hoje.

Sua primeira fila, à mão [12]

Antes de qualquer Java, vamos provocar no painel tudo o que o fluxo animado mostrou: Ready, entrega sem ack, reentrega, consumo e mensagem sem rota. Usaremos uma fila de treino descartável, treino.cafe. Nas filas pagamentos.* e pedidos.*, depois, só observe.

1. Abra o painel. http://localhost:15672, usuário aula, senha aula-local (veja o ponto 11). Algumas seções das páginas vêm recolhidas: clique no título para abri-las. Os contadores atualizam a cada poucos segundos.
2. Crie a fila. Aba Queues and Streams → Add a new queue (fica no fim da página). Preencha: Virtual host / (o padrão), Type deixe o padrão, Name treino.cafe, Durability Durable, Arguments em branco → Add queue.
3. Publique três mensagens. Clique em treino.cafe → seção Publish message. Payload é o corpo da mensagem, a “carta” do ponto 06. Nele, escreva {"texto":"café 1"} e publique. Repita com café 2 e café 3. Preveja antes de olhar: quanto marca Ready?
4. Espie sem consumir. Seção Get messages. O campo Ack Mode diz o que o painel responde ao RabbitMQ depois de pegar a mensagem: Nack message requeue true (“não processei, devolva”), Automatic ack (“confirmado”, a mensagem some), e duas variantes de Reject. Escolha Nack message requeue true, Messages = 1 → Get Message(s). Você vê a mensagem, e ela volta para a fila. Faça de novo e procure o campo Redelivered.
5. Consuma de verdade. Mesmo lugar, Ack Mode = Automatic ack → Get Message(s). Preveja: e agora, Ready?
6. Roteie por uma exchange topic. Aba Exchanges → amq.topic (já vem pronta: as exchanges com prefixo amq. são criadas pelo próprio RabbitMQ) → Add binding from this exchange: para a fila treino.cafe, chave cafe.# → Bind. Publique nessa exchange com chave cafe.expresso. Depois publique com chave cha.verde e leia o aviso que aparece.
7. Limpe só o que é seu. Na fila treino.cafe, Delete Queue. Nenhuma outra.

Siga a mensagem. Observe o estado. [13]

Agora juntamos tudo: HTTP, banco, exchange, fila, consumidor e o caminho de volta. Avance um passo por vez. Primeiro diga o que espera ver; depois confira estado do pedido, lugar da mensagem e evidência. O desenho é uma simulação didática, sem conexão com seu Docker.

Dois serviços, cada um com seus dados [14]

No desenho, host é o seu computador, do lado de fora dos containers. Docker executa o PostgreSQL e o RabbitMQ. As duas aplicações Java rodam em terminais separados no IntelliJ. Não é preciso colocar tudo em containers para usar mensageria.

Antes do código, combine a mensagem [15]

O ponto 07 separou comando (“processe este pagamento”) de evento (“este pagamento foi aprovado ou recusado”). Agora escrevemos o formato exato de cada um. O JSON é o contrato que os dois serviços precisam entender — e, como são implantados separadamente, ele precisa ser explícito.

A resposta de negócio preserva os IDs e o valor e acrescenta aprovado e motivo. O cliente não escolhe o valor enviado ao serviço; a API o lê do pedido.

[TAREFA] Escreva uma spec curta para pagamentos assíncronos simulados, antes de implementar.
Declare desde o início as filas pagamentos.solicitacoes.erros e pedidos.resultados.erros. Configure as filas principais para encaminhar falhas a elas, evitando mudar argumentos de filas já existentes durante a aula.
Contrato HTTP: POST /pedidos/{pedidoId}/pagamentos recebe solicitacaoId UUID e cenario APROVAR ou RECUSAR. O valor vem do pedido, não do cliente. Use POST /pedidos e GET /pedidos/{id} existentes.
Estados: ABERTO passa a EM_PAGAMENTO; aprovação passa a PAGO; recusa volta a ABERTO. Itens não mudam durante EM_PAGAMENTO. Pedido ausente: 404; estado incompatível ou chave reutilizada com outro conteúdo: 409; formato inválido: 400.
Mensagens JSON versão 1: solicitação com solicitacaoId, pedidoId, valor, cenario; resultado com os mesmos IDs/valor, aprovado e motivo. Exchange direct pagamentos.comandos + chave pagamento.solicitar → fila pagamentos.solicitacoes. Na volta: pagamentos.eventos + pagamento.resultado → pedidos.resultados.
[ACEITE] 202 só após confirmação do broker e verificação de roteamento; nunca significa aprovado. Defina repetição persistente, resultado conflitante, reinício e recuperação após falha de publicação.
[LIMITES] Sem cobrança real, sem banco compartilhado entre serviços, sem afirmar transação única entre Postgres e RabbitMQ. O endpoint síncrono antigo de aprovação deve sair da versão assíncrona.
[PAUSA] Liste dúvidas, arquivos e testes em etapas pequenas. Aguarde meu OK.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

O que o agente vai escrever: Spring AMQP em três peças [16]

O agente vai gerar dezenas de linhas. Você só consegue revisar o que reconhece. Spring AMQP é a biblioteca que conecta uma aplicação Spring ao RabbitMQ; ela resume o trabalho em três peças. Leia cada uma pelo efeito, não pela sintaxe.

1. Declarar a topologia: exchange, fila e binding

Ao subir, a aplicação pede ao broker que crie (se ainda não existirem) a exchange, a fila e a ligação entre elas. Por isso a fila aparece no painel assim que Pedidos liga.

@Bean
Declarables topologia() {
    var comandos = new DirectExchange("pagamentos.comandos");          // 1. a exchange
    var solicitacoes = QueueBuilder.durable("pagamentos.solicitacoes") // 2. a fila durável
            .deadLetterExchange("")                                     //    falhou de vez? vai para...
            .deadLetterRoutingKey("pagamentos.solicitacoes.erros")       //    ...esta fila de erros
            .build();
    var ligacao = BindingBuilder.bind(solicitacoes)                     // 3. o binding
            .to(comandos).with("pagamento.solicitar");
    return new Declarables(comandos, solicitacoes, ligacao);
}

2. Publicar: o RabbitTemplate

O RabbitTemplate é para mensageria o que um cliente HTTP é para requisições: você diz para onde vai e o que vai. O objeto Java é convertido em JSON no caminho.

rabbitTemplate.convertAndSend(
        "pagamentos.comandos",   // exchange
        "pagamento.solicitar",   // chave de roteamento
        solicitacao);            // objeto Java -> JSON

A referência da aula vai um passo além: espera a confirmação do broker e verifica se a mensagem não voltou sem rota antes de seguir. Se qualquer das duas falhar, lança exceção — e a API responde 503 em vez de 202.

var correlacao = new CorrelationData();
rabbit.send(exchange, chave, mensagem, correlacao);
var confirmacao = correlacao.getFuture().get(5, TimeUnit.SECONDS); // espera o broker
if (!confirmacao.isAck() || correlacao.getReturned() != null)      // recusou ou voltou sem rota?
    throw new IllegalStateException("Publicação não confirmada ou sem rota.");

3. Consumir: o @RabbitListener

Uma anotação transforma um método comum em consumidor. O Spring abre a conexão, busca mensagens da fila e chama o método para cada uma. Ninguém faz requisição HTTP para Pagamentos.

@RabbitListener(queues = "pagamentos.solicitacoes")
public void receber(Message mensagem) throws Exception {
    var solicitacao = json.readValue(mensagem.getBody(), Solicitacao.class); // bytes -> objeto
    var resultado = decisoes.registrar(solicitacao);  // COMMIT da decisão
    publicador.enviar("pagamentos.eventos", "pagamento.resultado", resultado);
}   // terminou sem exceção -> o Spring envia o ack

E a configuração que liga tudo

spring:
  rabbitmq:
    publisher-confirm-type: correlated   # quero o publisher confirm
    publisher-returns: true              # quero saber de mensagem sem rota
    template:
      mandatory: true                    # devolva se não houver rota
    listener:
      simple:
        acknowledge-mode: auto           # ack depois que o método termina bem
        prefetch: 1                      # uma mensagem por vez
        default-requeue-rejected: false  # falhou de vez? não volta para a fila
        retry:
          enabled: true
          max-attempts: 3                # 3 tentativas, depois fila de erros

Pedidos publica. Ainda não aprova. [17]

Vamos construir somente a saída de Pedidos. Um publisher confirm é a confirmação enviada pelo broker ao produtor sobre a publicação. Também precisamos detectar mensagem devolvida por falta de rota; confirmar publicação não substitui conferir a fila de destino.

[CONTEXTO] Implemente somente a primeira etapa da spec aprovada: Pedidos recebe e publica a solicitação.
[TAREFA] Adicione Spring AMQP compatível com o Boot do projeto. Declare exchanges, filas duráveis e bindings, incluindo as filas de erro e seus encaminhamentos previstos na spec. Use JSON e mensagem persistente. Registre solicitacaoId e estado no Postgres, atualizando o pedido na mesma transação local. Publique após o registro usando confirmação correlacionada e detecção de retorno sem rota.
[LIMITES] Não marque o pedido como PAGO ao publicar. Não implemente Pagamentos ainda. Preserve o núcleo sem dependências de RabbitMQ. Remova o atalho HTTP antigo que recebia aprovação do cliente; registre a mudança de contrato.
[ACEITE] Com consumidor parado: solicitação válida recebe 202 após publicação confirmada; pedido EM_PAGAMENTO; mensagem visível na fila. Falha de publicação responde 503 e preserva a chave para recuperação, sem fingir sucesso. Repetir a mesma chave/conteúdo pendente permite republicar; conteúdo diferente é 409. Não há outbox nem reenvio automático neste laboratório.
[PAUSA] Mostre testes, diff e o roteiro de prova. Pare antes da próxima etapa.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

Monte sua bancada no Insomnia [18]

Uma collection reúne requisições salvas. Um ambiente guarda valores reutilizáveis, como a URL da API e o ID do pedido. A collection não executa todo o roteiro sozinha: você envia, observa e atualiza as variáveis indicadas.

Importe insomnia-pedidos.json pela opção de importação de arquivo. Abra o ambiente base: base_url começa em http://localhost:8080. Envie “01 · Criar pedido”; copie o campo id da resposta para pedido_id.

[TAREFA] Confira a collection fornecida e adapte apenas URLs e campos que divergirem do contrato aprovado. Preserve a ordem criar → consultar → solicitar → consultar novamente.
[ACEITE] Use variáveis de ambiente base_url, pedido_id, pedido_recusa_id e chaves estáveis de solicitação. Explique quais valores eu copio da resposta e onde colo. Inclua aprovação, recusa, repetição, conflito e pedido ausente, com resposta esperada na descrição.
[LIMITES] Não gere um novo UUID em cada reenvio. Não crie endpoint para fingir aprovação e não substitua a API por mock. Não inclua credenciais pessoais.
[PAUSA] Mostre o arquivo importável e um roteiro de execução manual.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

Desligue o consumidor. A fila continua ali. [19]

Este é o momento em que o fluxo do ponto 04 vira realidade na sua máquina. Mantenha a API de Pedidos e o RabbitMQ ligados. O serviço de Pagamentos fica parado (ou ainda nem existe). Envie a solicitação, consulte o pedido e abra a fila pagamentos.solicitacoes no painel.

Não use “Purge” nem “Delete”. Essas ações removem mensagens ou a fila. Para apenas observar, os contadores bastam. Também não use “Get messages” durante a prova: no ponto 12 você viu que isso entrega a mensagem a você, e pode consumir ou reenfileirar e alterar sua observação.

Pagamentos recebe uma tarefa [20]

Um listener é o método configurado para receber as entregas da fila — o @RabbitListener do ponto 16. O Spring AMQP conecta esse método ao RabbitMQ. Ele não precisa de uma requisição HTTP para cada pagamento.

O simulador é determinístico: a mesma entrada sempre dá o mesmo resultado, sem sorteio — APROVAR aprova, RECUSAR recusa. Pagamentos terá sua própria memória durável no Postgres: uma decisão por solicitacaoId, protegida por uma restrição única no banco (a tabela recusa duas linhas com a mesma chave). Se a mesma solicitação chegar outra vez, lê a decisão já salva e devolve o mesmo resultado.

[CONTEXTO] A API publica solicitações versão 1 na fila pagamentos.solicitacoes.
[TAREFA] Crie a aplicação pagamentos na pasta pagamentos/, dentro deste mesmo repositório, como projeto Maven independente (não é módulo do pom de Pedidos), Java 21 e a mesma versão Boot de Pedidos, com seu Maven Wrapper. Use Spring AMQP e seu próprio banco pagamentos. Não leia tabelas de Pedidos. Configure porta 8081 para não conflitar.
Receba JSON validando versão, IDs, valor positivo e cenário. Simule APROVAR ou RECUSAR de forma determinística. Persista uma única decisão por solicitacaoId, com restrição única. Mesma chave com outro pedido, valor ou cenário deve falhar.
Após salvar a decisão, publique resultado na exchange pagamentos.eventos com chave pagamento.resultado. Preserve IDs e valor. Se receber novamente, reutilize a decisão salva e republique o mesmo resultado. Espere confirmação e detecte falta de rota.
[LIMITES] Sem SDK de banco financeiro, aleatoriedade, cartão ou cobrança real. Não confirme processamento antes de salvar e publicar. Configure tentativas limitadas e filas de erro para não criar loop infinito; documente sem aprofundar a operação de recuperação.
[ACEITE] Ao ligar o serviço, a mensagem pendente sai de Ready; o resultado aparece em pedidos.resultados se seu consumidor estiver parado. Um registro de pagamento sobrevive ao reinício.
[PAUSA] Mostre o plano antes de criar; após meu OK, execute, teste e mostre as provas.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

O resultado precisa voltar [21]

Uma fila esvaziar não atualiza o banco de Pedidos por mágica. Agora Pedidos se torna consumidor do resultado. Ele confere a identificação, aplica a transição da máquina de estados do ponto 13 e registra que aquela solicitação terminou.

[TAREFA] Implemente em Pedidos o consumidor da fila pedidos.resultados.
Valide versão 1, solicitacaoId existente, mesmo pedido e valor. Neste laboratório determinístico, resultado também deve corresponder ao cenário pedido. Resultado repetido já concluído não altera novamente o pedido. Resultado conflitante deve falhar com evidência e ir para tratamento de erro limitado.
Na mesma transação local, conclua a solicitação e aplique: aprovado → PAGO; recusado → ABERTO. Preserve ID, itens e total. Confirme processamento somente após concluir essa transação. Não reabra pedido pago por evento atrasado.
[ACEITE] Prove aprovação, recusa, resultado duplicado após reiniciar e conteúdo incompatível. Consultar o pedido deve revelar o estado final; logs sozinhos não bastam.
[LIMITES] Sem endpoint que aceite aprovado do cliente. Sem transação global entre bancos e RabbitMQ. Não capture exceções para fingir que tudo funcionou.
[PAUSA] Mostre diff, testes e evidências do fluxo completo.
[COMMIT] Só depois do meu OK sobre o diff: commit apenas dos arquivos desta etapa, mensagem em português dizendo o que mudou, e push para origin main. Sem segredos e sem force push. Mostre git log -1 --stat.

Quantas vezes uma mensagem chega? [22]

Três confirmações que não significam a mesma coisa [23]

O diagrama abaixo é um diagrama de sequência: cada coluna é um participante, o tempo corre de cima para baixo e cada seta é uma mensagem. Os números nas setas são as três confirmações da tabela.

Na configuração AUTO do Spring AMQP, o framework confirma após o listener terminar com sucesso. Isso é diferente de mandar o broker considerar a entrega concluída antes do processamento — o “Automatic ack” que você testou no painel.

A mesma mensagem pode chegar duas vezes [24]

[TAREFA] Proponha e execute uma prova de duplicidade usando somente os serviços e dados deste laboratório.
Com Pagamentos parado, publique duas vezes a mesma solicitacaoId com o mesmo conteúdo. Ligue o consumidor e confira uma decisão persistida e o pedido correto. Reinicie Pagamentos e Pedidos; republique o mesmo JSON diretamente no painel didático para testar o consumidor, não só a proteção do HTTP.
[ACEITE] Conte registros por chave, consulte o pedido e mostre que reiniciar não apaga a proteção contra duplicidade. Teste também a mesma chave com valor incompatível: deve ser rejeitada, sem mudar a decisão anterior.
[LIMITES] Não purgue filas nem apague volumes. Faça as publicações manuais apenas no ambiente local de aula. Explique por que enviar com UUID novo seria outra solicitação.
[PAUSA] Mostre o roteiro antes de executar ações; depois apresente resultados observados.
[COMMIT] Se esta etapa criou ou alterou arquivos (testes, roteiro de prova), só depois do meu OK: commit desses arquivos em português e push para origin main. Sem segredos e sem force push.

{"versao":1,"solicitacaoId":"ID-DA-SOLICITACAO","pedidoId":"ID-DO-PEDIDO","valor":37.80,"cenario":"APROVAR"}

Quando o fluxo para, encontre a fronteira [25]

Uma fila de erro (em inglês, dead letter queue, DLQ) guarda mensagens que não concluíram após as tentativas configuradas. Neste kit, são pagamentos.solicitacoes.erros e pedidos.resultados.erros. É uma contenção básica: a mensagem para de travar a fila e fica disponível para análise. Reprocessamento e políticas mais completas ficam para a continuação.

[CONTEXTO] Tenho um pedido EM_PAGAMENTO que ainda não terminou.
[TAREFA] Investigue antes de alterar. Siga solicitacaoId pelos registros e pelas filas. Confira Ready, Unacked, Consumers, mensagens de erro e conexão dos dois serviços. Separe observações de hipóteses.
[ACEITE] Localize a última fronteira comprovada e proponha a menor recuperação. Se publicação ficou incerta, reutilize a mesma chave e conteúdo. Se o contrato está inválido, explique a causa antes de reprocessar.
[LIMITES] Não apague volumes, não purgue filas, não marque manualmente o pedido como PAGO e não reenvie em loop infinito.
[PAUSA] Mostre diagnóstico e plano; aguarde meu OK.
[COMMIT] Se aprovarmos uma correção de código, commit só dela, em português, e push para origin main. Diagnóstico sem mudança não gera commit.

Agora conduza uma recusa e uma nova tentativa [26]

Crie um pedido novo. Solicite RECUSAR e prove que ele volta a ABERTO sem alterar itens ou total. Depois solicite APROVAR com outra solicitacaoId e prove que termina PAGO. Reenvie o resultado antigo da recusa: ele não deve reabrir o pedido.

Em sala, faça pelo menos a previsão escrita e a primeira metade (recusa). O restante segue para casa.

[CONTEXTO] Fiz recusa e depois aprovação para o mesmo pedido, com duas solicitacaoId distintas.
[TAREFA] Revise minhas evidências e o diff sem editar arquivos. Confira correlação, estado final, preservação do total e tratamento do resultado antigo repetido.
[ACEITE] Aponte problemas concretos com reprodução, ou justifique por que o comportamento está correto. Não invente um erro para preencher a revisão.
[LIMITES] Não adicionar framework ou serviço. Compare com a spec aprovada.
[PAUSA] Entregue um parecer curto: evidência, risco e correção mínima quando necessária.

Explique o sistema sem decorar anotações [27]

1. Quem guarda o trabalho quando Pagamentos está desligado — e quem não guarda?
2. Qual a diferença entre 202, publisher confirm e consumer ack?
3. Por que escolhemos “pelo menos uma vez”, e o que isso exige do consumidor?
4. Por que usar a mesma chave ao reenviar, e o que uma chave nova significa?
5. O que ainda não resolvemos entre banco e publicação?

Traga uma prova e uma dúvida [28]

Reproduza o fluxo a partir de uma pasta limpa usando o guia de execução. Registre aprovação, recusa e duplicidade após reinício. Termine o desafio do ponto 26. Escolha uma falha, peça um diagnóstico ao agente (prompt 9) e confira se ele preservou a evidência.

Entregue o link do seu repositório (branch main, com um commit por etapa), sua spec, os testes e uma explicação curta: “Meu pagamento estava pendente porque… A evidência foi… A recuperação foi…” Não basta uma captura de “BUILD SUCCESS”.

Para rever a teoria, percorra de novo os seis fluxos animados e tente narrar cada passo antes de clicar em avançar. Se consegue explicar a janela A e a janela B do ponto 23 sem olhar, você entendeu o essencial do dia.

O aprofundamento de OO/SOLID começa a partir do Cap 03. Mensageria volta adiante com recuperação, outbox, políticas de erro e outras decisões. O capítulo anterior de OO/SOLID foi preservado como material de referência para reorganização.