A rota de posting no Midaz
O Lender é a fonte de verdade da jornada de crédito; o Midaz é a fonte de verdade dos saldos. Um desembolso e cada apropriação de juros se tornam uma transação de balanceada destinada ao . O mesmo vale para um pagamento antecipado que liquida uma conta de empréstimo brasileira contra uma cotação de pagamento antecipado. A rota preserva essa intenção de posting e a entrega de forma idempotente. O ledger alcança consistência assim que a entrega do outbox é bem-sucedida e o dispatcher contabiliza, o que pode atrasar ou ficar pendente enquanto o roteamento estiver indisponível.
1
Um evento de domínio produz uma intenção de posting
Quando um empréstimo é desembolsado, juros são apropriados ou uma cotação de pagamento antecipado brasileira é liquidada, o Lender persiste uma intenção de posting durável na mesma transação de banco de dados que muda o estado do domínio. A intenção é gravada num outbox transacional, de modo que sobrevive a uma queda entre “o estado mudou” e “foi contabilizado no ledger”.
2
O relay contabiliza uma transação balanceada no Midaz
Quando o relay do ledger do Midaz está configurado, um dispatcher do outbox contabiliza a transação de partidas dobradas balanceada pelo SDK oficial. Caso contrário, a intenção durável fica no outbox. Os lançamentos vêm do perfil contábil do produto.
3
A idempotência é durável
Cada posting carrega uma chave de idempotência determinística calculada pelo Lender. Um posting reexecutado colapsa para a mesma transação do Midaz; a própria janela de idempotência do Midaz é um backstop, não a guarda principal.
4
O roteamento falha fechado
A transação é contabilizada na organização de ledger e no ledger que o perfil contábil resolve. Se o roteamento não consegue resolver um destino não vazio, o posting falha fechado (fail-closed) — o Lender se recusa a contabilizar em vez de gravar num destino vazio ou errado.
Eventos do ciclo de vida
O catálogo de streaming do Lender contém 33 definições: 31 fatos e dois comandos. Quando o streaming está habilitado e há um broker configurado, cada evento emitido pelo Lender é respaldado pelo outbox e tem escopo por tenant. A emissão em runtime também depende das flags de funcionalidade aplicáveis. Consulte o manifesto implantado e a referência de eventos do Lender antes de depender de uma definição como integração ativa. O Lender usa o contrato v3 de stream por aplicação:
Todos os fatos compartilham um tópico de aplicação e todos os comandos compartilham o tópico de comandos. Faça o roteamento por
ce-resourcetype e ce-eventtype; a versão do schema viaja em ce-schemaversion e não muda o tópico.
Como os eventos viajam pelo mesmo outbox que o relay do ledger, eles compartilham uma única garantia de durabilidade: a mudança de estado local e o evento são confirmados juntos numa única transação de banco de dados. A intenção de posting se junta a eles quando a mudança produz uma. O dispatcher do outbox aplica a contabilização no ledger depois, quando transmite a intenção ao Midaz — de modo que o estado do Lender e a contabilização no Midaz são eventualmente consistentes, não confirmados na mesma transação.
O Lender conecta 15 chaves do gateway de folha a partir de
lerian.streaming.consignado-gw; os consumidores correspondentes são controlados por configuração. Seu listener do Matcher consome match_run.completed de lerian.streaming.matcher; o contrato coincide somente quando o Matcher usa STREAMING_CLOUDEVENTS_SOURCE=matcher e envia ce-source: matcher, ce-type: studio.lerian.matcher.match_run.completed, ce-resourcetype: match_run e ce-eventtype: completed. Veja Eventos do Lender e Consignado privado.Multi-tenancy
Como todo produto Lerian, o Lender é construído para isolamento total de tenants desde a base.
- Persistência schema-por-tenant quando a multi-tenancy está habilitada, de modo que os dados de um tenant nunca compartilham tabela.
- Eventos e postings no ledger com escopo por tenant — cada evento emitido e cada transação do Midaz carrega o tenant ao qual pertence.
- No modo multi-tenant, o relay do ledger resolve um cliente do Midaz por tenant, e o perfil contábil fornece o destino de ledger por tenant (por isso o roteamento falha fechado quando um destino está faltando).
Observabilidade
O Lender emite logs estruturados, traces OpenTelemetry e métricas no mesmo stack de observabilidade do restante da plataforma, incluindo métricas de banco de dados, de asserções e de recuperação de panics. Veja Observabilidade.
Próximos passos
Contabilidade e rotinas de apropriação
Aprofunde nas regras de posting, nas rotinas de apropriação e nas referências de lançamento.
Configuração e implantação
Veja as dependências e a configuração que a rota de posting e o fluxo de eventos exigem.