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. Cada evento financeiro que um empréstimo produz é contabilizado no como uma transação de balanceada — e a rota é construída para nunca perder uma contabilização e nunca contabilizar no lugar errado.
Um evento de domínio produz uma intenção de posting
Quando um empréstimo é desembolsado, um repagamento é registrado, juros são apropriados ou uma transação é estornada, 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”.
O relay contabiliza uma transação balanceada no Midaz
Um dispatcher do outbox impulsiona o relay do ledger, que contabiliza a transação de partidas dobradas balanceada no Midaz através do SDK oficial. Os lançamentos vêm do perfil contábil do produto.
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.
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 Lender publica um catálogo de 14 eventos de negócio sobre o backbone de streaming da plataforma (RedPanda, através da biblioteca de streaming da Lerian). Cada evento é respaldado pelo outbox, tem escopo por tenant e carrega um
source de CloudEvents definido pelo seu deployment, que também serve de namespace para os tópicos de streaming, para que produtos downstream e os seus próprios serviços possam reagir à jornada de crédito à medida que ela avança. Assine pelo source que o seu deployment configura, em vez de um literal fixo.
| Domínio | Eventos |
|---|---|
| Produtos | loan_product.created, loan_product_version.created, loan_product.activated, accounting_profile.configured, loan_charge.applied |
| Originação | loan_application.submitted, loan_application.approved, loan_application.rejected, loan_application.withdrawn, loan_application.disbursed |
| Servicing | repayment.recorded, repayment_reversal.recorded, loan_schedule.prepayment_applied, loan_schedule.rescheduled |
A jornada brasileira de consignado privado contribui com seus próprios eventos por cima desse catálogo — sinais de margem, averbação e reconciliação. Veja 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.