Pular para o conteúdo
thiagoetipadrões

Contatos

apps/messaging-streaming/sqs-order-processor

077 · Comunicação & Mensageria · ≈ 5 min de estudo

SQS Order Processor

Point-to-Point com retry e DLQ usando AWS SQS Standard: um gateway de adquirência liquida cobranças (PIX/boleto) de forma assíncrona, com reprocessamento automático de falhas e Dead Letter Queue.

passos
6
arquivos
6
teste
1
tecnologias
4
Lógica puraTypeScriptBunAWS SQSMoto
CenárioRelaçõesComparar
Baixar cartão

Cenário

Um gateway de adquirência recebe cobranças dos lojistas (PIX e boleto) e as liquida de forma assíncrona: confirma na rede de liquidação e repassa ao lojista. Falha transitória da rede é reprocessada com atraso; esgotadas as tentativas, a cobrança vai para a DLQ sem travar as outras. Recusa de negócio — boleto vencido — vai para a DLQ na hora.

Planta

Fluxo
7/7
Gateway de adquirênciacharge-settlementSQS StandardConsumer de liquidaçãoDeleteMessageBatchChangeMessageVisibilitycom atrasocharge-settlement-dlqSendMessagelong poll só pelosslots livresliquidoufalha transitóriarecusa de negócioou ilegívelmaxReceiveCount
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Pedidos com retry e DLQ.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

RedrivePolicy+2
maxReceiveCount+2
ChangeMessageVisibility+2
WaitTimeSeconds: 20+1
Failed+1
  1. 01

    O producer envia cada cobrança à fila Standard; RedrivePolicy com maxReceiveCount aponta a DLQ

  2. 02

    O consumer faz long poll (WaitTimeSeconds: 20) pedindo só as mensagens que cabem nos slots livres e estende a visibilidade enquanto trata

  3. 03

    Liquidou → apaga em lote, conferindo Failed por entrada; o repasse leva o id da cobrança como chave de idempotência

  4. 04

    Falha transitória → ChangeMessageVisibility com o atraso da tentativa: o ApproximateReceiveCount sobe e o SQS move para a DLQ no limite

  5. 05

    Boleto vencido ou corpo ilegível → copiado para a DLQ com o motivo e apagado, sem gastar tentativas

  6. 06

    Nunca apagar antes do efeitoSe o processo cai no meio, a cobrança reaparece

apps/messaging-streaming/sqs-order-processor

6 arquivos

src/

  • charge_settlement.tsCobrança, envio, validação e regra de recusa do boleto vencido
  • worker_sqs.tsLoop de consumo: slots, heartbeat de visibilidade, delete em lote, retry por visibilidade e DLQ
  • consumer_charge.tsLiquidação e repasse com chave de idempotência
  • producer_charge.tsTrês cobranças, uma de boleto vencido
  • config_charge.tsVariáveis de ambiente validadas no boot
  • worker_sqs.test.tstesteIntegração com moto: delete após o efeito com teto de slots, redrive após maxReceiveCount, recusa direta à DLQ e limite do vencimento

Executar · só Bun

  1. cp .env.example .env# variáveis de ambiente
  2. bun install# dependências
  3. bun run consumer# terminal 1
  4. bun run demo# terminal 2
  5. bun run test# testes unitários

Roda contra a AWS: exige credenciais pela cadeia padrão do SDK e a fila com DLQ criadas pela IaC. Os testes rodam contra o moto.

Requisitos
Bun
Sobe junto
Moto

Relações

Onde ele se encaixa

Mapa
  1. SQS Order Processor
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com SQS Order Processor?

Próximo projeto · Dados & PersistênciaCQRS (Command Query Responsibility Segregation)
Esc

↑ ↓ navegarEnter abrir191 resultados