Skip to main content
Lender es una primitiva de Lerian: corre sobre la plataforma, no al lado. Cuatro uniones con la plataforma importan cuando lo operas: la ruta de asiento en el ledger, el stream de eventos, el multi-tenancy y la observabilidad.

La ruta de asiento en Midaz


Lender es la fuente de verdad del recorrido de crédito. Midaz es la fuente de verdad de los saldos. Un desembolso y cada devengo de intereses se convierten en una transacción balanceada de destinada al . Lo mismo ocurre con un pago anticipado que liquida una cuenta de préstamo brasileña contra una cotización de pago anticipado. La ruta conserva esa intención de asiento y la entrega de forma idempotente. El ledger alcanza consistencia una vez que la entrega del outbox tiene éxito y el despachador asienta, lo que puede demorarse o quedar pendiente mientras el enrutamiento no está disponible.
1

Un evento de dominio produce una intención de asiento

Lender persiste una intención de asiento durable en un desembolso, un devengo de intereses o la liquidación de una cotización de pago anticipado brasileña. La intención aterriza en la misma transacción de base de datos que cambia el estado del dominio. Lender escribe la intención en un outbox transaccional, así sobrevive a una caída entre “el estado cambió” y “el ledger contabilizó”.
2

El relay asienta una transacción balanceada en Midaz

Con el relay del ledger de Midaz configurado, un despachador del outbox asienta la transacción balanceada de partida doble a través del SDK oficial. De lo contrario, la intención durable permanece en el outbox. Las patas vienen del perfil contable del producto.
3

La idempotencia es durable

Cada asiento lleva una clave de idempotencia determinista que calcula Lender. Un asiento reintentado colapsa en la misma transacción de Midaz. La propia ventana de idempotencia de Midaz es un respaldo, no la protección principal.
4

El enrutamiento falla en modo cerrado

La transacción se contabiliza en la organización de ledger y el ledger que resuelve el perfil contable. Si el enrutamiento no puede resolver un destino no vacío, el asiento falla en modo cerrado: Lender se niega a contabilizar en lugar de escribir en un destino vacío o equivocado.
Con el relay del ledger configurado, Lender llega a Midaz a través de Access Manager. Se autentica con credenciales machine-to-machine (M2M) y un JWT de corta duración, por tenant.

Eventos de ciclo de vida


El catálogo de streaming de Lender contiene 35 definiciones: 33 hechos y dos comandos. Con el streaming habilitado y un broker configurado, cada evento que Lender emite está respaldado por el outbox y tiene alcance por tenant. La emisión en tiempo de ejecución también depende de los feature gates aplicables. Revisa el manifiesto desplegado y la Referencia de eventos de Lender antes de depender de una definición como integración viva. Lender usa el contrato de stream de aplicación v3: Todos los hechos comparten un tema de aplicación, y todos los comandos comparten el tema de comandos. Enruta por ce-resourcetype y ce-eventtype. La versión de esquema viaja en ce-schemaversion y no cambia el tema. Los eventos viajan por el mismo outbox que el relay del ledger, así comparten una sola garantía de durabilidad. El cambio de estado local y el evento hacen commit juntos en una sola transacción de base de datos. La intención de asiento se les suma cuando el cambio produce una. El despachador del outbox aplica el asiento en el ledger después, cuando transmite la intención a Midaz. Por eso el estado de Lender y la contabilización en Midaz alcanzan consistencia más tarde, no en la misma transacción.
Lender conecta 15 claves del gateway de nómina desde lerian.streaming.consignado-gw. Los consumidores correspondientes dependen de la configuración. Su listener de Matcher consume match_run.completed desde lerian.streaming.matcher. El contrato coincide solo cuando Matcher usa STREAMING_CLOUDEVENTS_SOURCE=matcher y envía ce-source: matcher, ce-type: studio.lerian.matcher.match_run.completed, ce-resourcetype: match_run y ce-eventtype: completed. Consulta Eventos de Lender y Consignado privado.

Multi-tenancy


Como todo producto Lerian, Lender está construido para el aislamiento total de tenants desde la base.
  • Persistencia con un esquema por tenant cuando el multi-tenancy está habilitado, así los datos de un tenant nunca comparten una tabla.
  • Eventos y asientos en el ledger con alcance por tenant: cada evento emitido y cada transacción de Midaz llevan el tenant al que pertenecen.
  • En modo multi-tenant, el relay del ledger resuelve un cliente de Midaz por tenant. El perfil contable aporta el destino de ledger por tenant. Por eso el enrutamiento falla en modo cerrado cuando el perfil no aporta un destino.
Consulta Multi-tenancy para el modelo de toda la plataforma.

Observabilidad


Lender emite logs estructurados, trazas de OpenTelemetry y métricas en el mismo stack de observabilidad que el resto de la plataforma, incluidas las métricas de base de datos, de aserciones y de recuperación de panics. Consulta Observabilidad.

Próximos pasos


Contabilidad y ejecuciones de devengo

Profundiza en las reglas de asiento, las ejecuciones de devengo y las referencias de diario.

Configuración y despliegue

Consulta las dependencias y la configuración que requieren la ruta de asiento y el stream de eventos.