Skip to main content
Lender es un primitivo de Lerian: corre sobre la plataforma, no al lado de ella. Cuatro costuras con la plataforma importan cuando lo operas — la ruta de posting al ledger, el flujo de eventos, la multi-tenancy y la observabilidad.

​
La ruta de posting a Midaz

Lender es la fuente de verdad de la jornada de crédito; Midaz es la fuente de verdad de los saldos. Un desembolso y cada devengo de interés se vuelven una transacción de balanceada destinada al . También un prepago que liquida una cuenta de préstamo brasileña contra una cotización de prepago. La ruta preserva esa intención de posting y la entrega de forma idempotente. El ledger alcanza consistencia una vez que la entrega del outbox tiene éxito y el dispatcher contabiliza, lo que puede demorarse o quedar pendiente mientras el enrutamiento no esté disponible.
1

Un evento del dominio produce una intención de posting

Cuando un préstamo se desembolsa, se devenga interés o se liquida una cotización de prepago brasileña, Lender persiste una intención de posting durable en la misma transacción de base de datos que cambia el estado del dominio. La intención se escribe en un outbox transaccional, de modo que sobrevive a una caída entre “el estado cambió” y “se contabilizó en el ledger”.
2

El relay contabiliza una transacción balanceada en Midaz

Cuando el relay del ledger de Midaz está configurado, un dispatcher del outbox contabiliza la transacción de partida doble balanceada mediante el SDK oficial. De lo contrario, la intención durable queda en el outbox. Los asientos vienen del perfil contable del producto.
3

La idempotencia es durable

Cada posting lleva una clave de idempotencia determinista calculada por Lender. Un posting reintentado colapsa a la misma transacción de Midaz; la propia ventana de idempotencia de Midaz es un respaldo, no la guarda principal.
4

El enrutamiento falla 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 posting falla cerrado (fail-closed) — Lender se niega a contabilizar en lugar de escribir en un destino vacío o equivocado.
Cuando el relay del ledger está configurado, Lender llega a Midaz a través de Access Manager: se autentica con credenciales máquina-a-máquina (M2M) y un JWT de vida corta, por tenant.

​
Eventos del ciclo de vida

Cuando el streaming está habilitado y hay un broker configurado, Lender publica los 21 eventos de negocio de la jornada de crédito documentada sobre el backbone de streaming de la plataforma (RedPanda, a través de la librería de streaming de Lerian). Cada evento está respaldado por el outbox y es de alcance por tenant, para que los productos downstream y tus propios servicios puedan reaccionar a la jornada de crédito a medida que avanza. El source de CloudEvents de Lender es el literal fijo lender. Configura STREAMING_CLOUDEVENTS_SOURCE=lender — streaming exige ese valor, y el source también sirve de namespace para cada topic. Así, un suscriptor lee: Suscríbete por topic. Los topics se agrupan por dominio: Como los eventos viajan por el mismo outbox que el relay del ledger, comparten una sola garantía de durabilidad: el cambio de estado local y el evento se confirman juntos en una sola transacción de base de datos. La intención de posting se les suma cuando el cambio produce una. El dispatcher del outbox aplica la contabilización en el ledger después, cuando transmite la intención a Midaz — de modo que el estado de Lender y la contabilización en Midaz son eventualmente consistentes, no se confirman en la misma transacción.
La jornada de consignado privado también consume hechos del gateway de descuento en nómina, en los topics de ese producto. Consulta Consignado privado.

​
Multi-tenancy

Como todo producto Lerian, Lender está construido para aislamiento total de tenants desde su base.
  • Persistencia schema-por-tenant cuando la multi-tenancy está habilitada, de modo que los datos de un tenant nunca comparten tabla.
  • Eventos y postings al ledger de alcance por tenant — cada evento emitido y cada transacción de Midaz lleva el tenant al que pertenece.
  • En modo multi-tenant, el relay del ledger resuelve un cliente de Midaz por tenant, y el perfil contable aporta el destino de ledger por tenant (por eso el enrutamiento falla cerrado cuando falta un destino).
Consulta Multi-tenancy para el modelo a nivel de plataforma.

​
Observabilidad

Lender emite logs estructurados, trazas OpenTelemetry y métricas sobre el mismo stack de observabilidad que el resto de la plataforma, incluyendo 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 posting, las ejecuciones de devengo y las referencias de asiento.

Configuración y despliegue

Mira las dependencias y la configuración que requieren la ruta de posting y el flujo de eventos.