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.
Eventos del ciclo de vida
El catálogo de streaming de Lender contiene 33 definiciones: 31 hechos y dos comandos. Cuando el streaming está habilitado y hay un broker configurado, cada evento que emite Lender está respaldado por el outbox y tiene alcance por tenant. La emisión en runtime también depende de las flags de funcionalidad aplicables. Consulta el manifiesto desplegado y la referencia de eventos de Lender antes de depender de una definición como integración activa. Lender usa el contrato v3 de stream por aplicación:
Todos los hechos comparten un topic de aplicación y todos los comandos comparten el topic de comandos. Enruta por
ce-resourcetype y ce-eventtype; la versión del schema viaja en ce-schemaversion y no cambia el topic.
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.
Lender conecta 15 claves del gateway de nómina desde
lerian.streaming.consignado-gw; los consumidores correspondientes se controlan mediante 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 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).
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.