Pular para o conteúdo principal
O Lerian Consignado — Dataprev é event-first na sua borda com a plataforma. Ele consome comandos do motor de crédito e emite fatos de negócio; não faz chamadas diretas ao ledger nem hospeda consumidores de webhook. Seu contrato autoritativo é o fluxo de eventos, não a sua superfície REST.

Comandos que consome


O gateway consome dois comandos do motor de crédito, transportados como eventos pelo backbone de streaming da plataforma:
  • uma solicitação de margem, que pede a margem de folha disponível de um trabalhador;
  • uma solicitação de averbação, que pede o registro de um contrato assinado na Dataprev.
Um comando que decodifica mas está sem a sua chave identificadora — por exemplo o CPF do trabalhador — é terminal: ele vai para a fila de mensagens mortas em vez de ser repassado à Dataprev.

Fatos que emite


O gateway emite cinco fatos de negócio:
  • a margem obtida de um trabalhador;
  • um resultado de averbação confirmada;
  • um resultado de averbação rejeitada;
  • um sinal de proposta aceita, que diz ao sistema de empréstimos a jusante para originar;
  • um registro de conciliação — um por registro de escrituração ou de liquidação.
Cada fato carrega uma única versão de esquema para todo o pacote, estampada de forma idêntica nos cinco em vez de versionada por evento.

Entrega agnóstica ao destino


O gateway escreve cada fato em um outbox transacional e repassa a partir dali. Ele não possui roteamento por destino: um hub de streaming a jusante decide qual sistema recebe cada fato. O mesmo fato pode ser distribuído a um ledger, a um armazenamento de conciliação ou a um sistema de empréstimos sem que o gateway saiba ou se importe com quem o consome.

Sem acoplamento direto com o ledger ou com webhooks


O gateway não faz chamadas diretas ao Midaz e não hospeda consumidores de webhook. O contato com o tomador fora da plataforma está fora de escopo: o fato de proposta aceita é o limite de repasse, após o qual o sistema de empréstimos a jusante é dono da originação e de qualquer comunicação com o tomador.

No transporte


  • Dinheiro e taxas cruzam como strings decimais, nunca como ponto flutuante, para não perder precisão no caminho.
  • Os carimbos de tempo são UTC, RFC 3339.
  • Nenhum CPF cruza o fato de conciliação. Isso é garantido por construção: os tipos de registro de conciliação não têm campo de CPF, o CPF presente na fonte de escrituração é descartado no normalizador, e os testes verificam que o payload serializado não contém nenhum CPF. O número de contrato é a chave de correspondência, então nenhum identificador pessoal é necessário a jusante. (Os fatos de margem e de proposta aceita carregam um CPF, porque cada um é associado a um trabalhador ou a uma proposta específicos.)
  • O repasse da CEF liquida por movimento diário, não por contrato, então a conciliação do lado bancário se baseia no identificador da transferência e não no número de contrato.

Semântica de entrega


  • Idempotente por sujeito imutável. Cada registro e cada liquidação carrega um identificador imutável; reprocessá-lo é um no-op a jusante.
  • Ao menos uma vez. Os eventos são entregues ao menos uma vez; a reentrega e os reinícios se deduplicam a um no-op.
  • Pernas independentes. Na conciliação, as pernas de escrituração e de repasse são processadas de forma independente — uma que falhe nunca bloqueia a outra.