> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # O Lender na plataforma > Veja como o Lender lança no ledger Midaz, emite eventos de ciclo de vida no backbone de streaming, isola tenants por schema e reporta dados de telemetria. export const GDoubleEntry = ({children}) => {children} ; export const GLedger = ({children}) => {children} ; O Lender é um primitivo Lerian: ele roda na plataforma, não ao lado dela. Quatro encaixes da plataforma importam quando você o opera: o caminho de lançamento no ledger, o stream de eventos, o multi-tenancy e a observabilidade. ## O caminho de lançamento no Midaz *** O Lender é a fonte da verdade da jornada de crédito. O [Midaz](/pt/products/midaz/about-midaz) é a fonte da verdade dos saldos. Um desembolso e cada apropriação de juros viram uma transação balanceada de partidas dobradas destinada ao ledger. O mesmo vale para um pagamento antecipado que liquida uma conta de empréstimo brasileira contra uma cotação de pagamento antecipado. O caminho preserva essa intenção de lançamento e a entrega de forma idempotente. O ledger chega à consistência assim que a entrega pelo outbox tem sucesso e o dispatcher lança, o que pode atrasar ou ficar pendente enquanto o roteamento estiver indisponível. O Lender persiste uma **intenção de lançamento** durável em um desembolso, em uma apropriação de juros ou na liquidação de uma cotação brasileira de pagamento antecipado. A intenção cai na mesma transação de banco de dados que muda o estado do domínio. O Lender grava a intenção em um **outbox** transacional, então ela sobrevive a uma queda entre "estado mudou" e "ledger contabilizou." Com o relay do ledger Midaz configurado, um dispatcher do outbox lança a transação balanceada de partidas dobradas pelo SDK oficial. Caso contrário, a intenção durável fica no outbox. As pernas vêm do **perfil contábil** do produto. Cada lançamento carrega uma chave de idempotência determinística calculada pelo Lender. Um lançamento repetido colapsa na mesma transação do Midaz. A janela de idempotência do próprio Midaz é uma proteção secundária, não a garantia principal. A transação é contabilizada na organização de ledger e no ledger que o perfil contábil resolve. Se o roteamento não conseguir resolver um destino não vazio, o lançamento **falha fechado**: o Lender recusa contabilizar em vez de gravar em um destino vazio ou errado. Com o relay do ledger configurado, o Lender chega ao Midaz pelo [Access Manager](/pt/platform/access-manager). Ele se autentica com credenciais máquina a máquina (M2M) e um JWT de vida curta, por tenant. ## Eventos de ciclo de vida *** O catálogo de streaming do Lender tem 35 definições: 33 fatos e dois comandos. Com o streaming habilitado e um broker configurado, cada evento que o Lender emite é **apoiado no outbox** e **delimitado por tenant**. A emissão em runtime também depende dos controles de funcionalidade aplicáveis. Confira o manifesto em produção e a [Referência de eventos do Lender](/pt/reference/events/lender) antes de depender de uma definição como integração real. O Lender usa o contrato v3 de stream de aplicação: | Elemento de transmissão | Valor | | ----------------------- | ----------------------------------------- | | Tópico de fatos | `lerian.streaming.lender` | | Tópico de comandos | `lerian.streaming.lender.commands` | | header `ce-source` | `lender` | | header `ce-type` | `studio.lerian.lender..` | | Chave de partição | o tenant | Todos os fatos compartilham um tópico de aplicação, e todos os comandos compartilham o tópico de comandos. Roteie por `ce-resourcetype` e `ce-eventtype`. A versão de schema viaja em `ce-schemaversion` e não muda o tópico. Os eventos andam no mesmo outbox do relay do ledger, então compartilham uma garantia de durabilidade. A mudança de estado local e o evento fazem commit juntos em uma única transação de banco de dados. A intenção de lançamento se junta a eles quando a mudança produz uma. O dispatcher do outbox aplica o lançamento no ledger depois, quando repassa a intenção ao Midaz. O estado do Lender e a contabilização no Midaz chegam, portanto, à consistência mais tarde, e não na mesma transação. O Lender conecta 15 chaves do gateway de folha de pagamento em `lerian.streaming.consignado-gw`. Os consumidores correspondentes são controlados por configuração. O listener de Matcher dele consome `match_run.completed` em `lerian.streaming.matcher`. O contrato bate apenas 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](/pt/products/lender/lender-events) e [Consignado privado](/pt/products/lender/consignado-privado). ## Multi-tenancy *** Como todo produto Lerian, o Lender é construído para isolamento total entre tenants desde a base. * Persistência com **schema por tenant** quando o multi-tenancy está habilitado, então os dados de um tenant nunca dividem uma tabela. * Eventos e lançamentos no ledger **delimitados por tenant**: cada evento emitido e cada transação do Midaz carrega o tenant a que pertence. * No modo multi-tenant, o relay do ledger resolve um cliente Midaz **por tenant**. O perfil contábil fornece o destino de ledger por tenant. O roteamento, portanto, falha fechado quando o perfil não fornece destino. Veja [Multi-tenancy](/pt/platform/multi-tenancy) para o modelo de toda a plataforma. ## Observabilidade *** O Lender emite logs estruturados, traces OpenTelemetry e métricas no mesmo stack de observabilidade do resto da plataforma, incluindo métricas de banco de dados, de asserção e de recuperação de panic. Veja [Observabilidade](/pt/platform/observability). ## Próximos passos *** Aprofunde em regras de lançamento, rodadas de apropriação e referências de diário. Veja as dependências e a configuração que o caminho de lançamento e o stream de eventos exigem.