Pular para o conteúdo
thiagoetipadrões

Contatos

apps/messaging-streaming/async-messaging

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

Async Messaging

O cliente envia a operação e recebe um identificador na hora, sem esperar o processamento. Um worker em outro processo consome a fila no seu ritmo; o cliente consulta o resultado depois. Produtor e consumidor evoluem e escalam de forma independente.

passos
6
arquivos
9
testes
2
tecnologias
6
Infraestrutura realTypeScriptBunElysiaRedisBullMQDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Um banco digital recebe pedidos de crédito cuja análise consulta bureau e score e leva segundos. A API aceita o pedido, responde 202 com o jobId e devolve a conexão; o worker decide em background: aprova até R$ 50.000,00, manda acima disso para análise manual e recusa conta bloqueada sem gastar tentativas.

Planta

Sequência
7/7
POST /credit-requests REQ-0011add com jobId credit-REQ-0012202 + jobId (não espera a análise)3consome em background, concurrency 3pega o job, consulta bureau, decide4completed com a decisão, ou failed (UnrecoverableError)5GET /credit-requests/REQ-0016state + decision7ClienteAPI de crédito (Elysia)Fila credit-approval (BullMQ/Redis)Worker de crédito
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Envia e segue, sem esperar resposta.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

jobId+1
UnrecoverableError+1
  1. 01

    POST /credit-requests valida o corpo, enfileira com jobId = credit-{requestId} e responde 202 — reenvio do mesmo pedido devolve o mesmo job

  2. 02

    O worker, em processo próprio, consome com concurrency: 3 e valida o payload como entrada externa

  3. 03

    Falha transitória (timeout do bureau) é relançada e retentada com backoff exponencial e full jitter, até 3 tentativas

  4. 04

    Recusa definitiva (conta bloqueada) lança UnrecoverableError e vai direto para o conjunto *failed*, que é a DLQ

  5. 05

    GET /credit-requests/:requestId devolve o estado e a decisão guardados no job

  6. 06

    SIGTERMReadiness 503, worker.close() com prazo de drenagem e close(true) se estourar

apps/messaging-streaming/async-messaging

9 arquivos

src/

  • credit_approval.tsDecisão de crédito pura: limite automático e taxa por finalidade
  • queue_credit.tsDefinição da fila, schema do job, conexão pelo RedisClient do Bun, retenção e retry
  • api_credit.tsAPI Elysia: 202 com jobId e consulta de status
  • worker_credit.tsWorker com probes e drenagem no SIGTERM
  • config_credit.tsLê e valida a configuração no boot
  • demo.tsdemoSobe API e worker, envia pedidos (um duplicado, um bloqueado) e consulta o status
  • credit_approval.test.tstesteUnitário: fronteira do limite automático e taxas
  • worker_credit.test.tstesteIntegração com Redis real: 202, deduplicação por jobId, retry e UnrecoverableError

./

  • docker.shinfraSobe o Redis na porta 6380

Executar · com Docker

  1. ./docker.sh up# sobe Redis
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário

Testes: bun run test.

Requisitos
BunDocker
Sobe junto
Redis

Relações

Onde ele se encaixa

Mapa
  1. Asynchronous Messaging
  • Combina com3
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Asynchronous Messaging?

Próximo projeto · Comunicação & MensageriaPub/Sub
Esc

↑ ↓ navegarEnter abrir191 resultados