> ## 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.

# Lender en la plataforma

> Descubre cómo Lender asienta en el ledger de Midaz, emite eventos de ciclo de vida en el backbone de streaming, aísla tenants por esquema y reporta datos de telemetría.

export const GDoubleEntry = ({children}) => <Tooltip headline="Partida doble" tip="Cada movimiento financiero se registra como al menos dos operaciones: un débito en una cuenta y un crédito en otra, lo que garantiza que el sistema siempre cuadra." cta="Ver glosario" href="/es/start-here/glossary">
    {children}
  </Tooltip>;

export const GLedger = ({children}) => <Tooltip headline="Ledger" tip="El libro financiero central que registra todas las transacciones, saldos y operaciones de una organización. Es la única fuente de verdad de las finanzas de una unidad de negocio." cta="Ver glosario" href="/es/start-here/glossary">
    {children}
  </Tooltip>;

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/products/midaz/about-midaz) es la fuente de verdad de los saldos. Un desembolso y cada devengo de intereses se convierten en una transacción balanceada de <GDoubleEntry>partida doble</GDoubleEntry> destinada al <GLedger>ledger</GLedger>. 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.

<Steps>
  <Step title="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ó".
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

Con el relay del ledger configurado, Lender llega a Midaz a través de [Access Manager](/es/platform/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](/es/reference/events/lender) antes de depender de una definición como integración viva.

Lender usa el contrato de stream de aplicación v3:

| Elemento de cable  | Valor                                     |
| ------------------ | ----------------------------------------- |
| Tema de hechos     | `lerian.streaming.lender`                 |
| Tema de comandos   | `lerian.streaming.lender.commands`        |
| Header `ce-source` | `lender`                                  |
| Header `ce-type`   | `studio.lerian.lender.<resource>.<event>` |
| Clave de partición | el tenant                                 |

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.

<Info>
  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](/es/products/lender/lender-events) y [Consignado privado](/es/products/lender/consignado-privado).
</Info>

## 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](/es/platform/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](/es/platform/observability).

## Próximos pasos

***

<Card title="Contabilidad y ejecuciones de devengo" icon="calculator" href="/es/products/lender/accounting-and-accrual-runs" horizontal>
  Profundiza en las reglas de asiento, las ejecuciones de devengo y las referencias de diario.
</Card>

<Card title="Configuración y despliegue" icon="gear" href="/es/products/lender/configuration-and-deploy" horizontal>
  Consulta las dependencias y la configuración que requieren la ruta de asiento y el stream de eventos.
</Card>