API de Pedidos e Pagamentos

O problema deste projeto não é o CRUD de produtos. É o que acontece quando a aplicação depende de outro sistema: o webhook que chega duas vezes, e a gravação no banco que precisa acontecer junto com a publicação na fila sem que exista transação entre os dois.

Demonstração ao vivo: a mesma requisição, duas vezes

Criar um pedido exige o cabeçalho Idempotency-Key. O botão abaixo envia a mesma requisição duas vezes, com a mesma chave — é o que acontece quando um cliente perde a resposta por timeout e tenta de novo.

A primeira volta 201 Created. A segunda volta 200 OK com o mesmo pedido, e o estoque sai uma vez só.

Pronto. Clique no botão acima.

O que mais está no ar

• Webhook idempotente — assinatura HMAC verificada, e o id do evento gravado na mesma transação do efeito. A segunda entrega colide na restrição de unicidade e não produz efeito novo.
• Padrão outbox — o evento do pedido pago é gravado na mesma transação do pedido; um worker publica depois e só marca como entregue após a confirmação do broker.
• Consumidores idempotentes — baixa de estoque e notificação, cada um com o próprio registro de consumo.
• Expiração automática — pedido não pago devolve o estoque ao catálogo.

O serviço roda no plano gratuito do Render e hiberna quando ocioso — a primeira requisição depois de um tempo parado leva cerca de um minuto para responder — as seguintes são imediatas.
João Vitor Alcântara Corrêa · GitHub · LinkedIn