Arquitectura de Lender

Lender es un solo servicio. Dentro de él, cinco dominios son dueños de la jornada de crédito, un perfil de jurisdicción aporta cada regla específica del mercado, y el dinero llega al ledger a través de una cola durable en lugar de una llamada en línea. Esos tres hechos explican casi todo lo que sigue.

​

Cinco dominios, un servicio

---

Cada dominio es dueño de sus propias tablas y de sus propias operaciones. El identificador de la cuenta de préstamo es la clave que los une. Lender no acuña ese identificador — lo aportas tú cuando desembolsas, y desde ahí cada dominio direcciona el préstamo por él.

​

La costura de jurisdicción

---

Las reglas de crédito difieren por mercado, así que ningún dominio nombra un mercado. Todo lo específico del mercado llega a través de un perfil de jurisdicción, que aporta un conjunto fijo de capacidades:

• El motor de impuestos que calcula las retenciones en el desembolso y los impuestos sobre ingresos en el devengo.
• El calendario de feriados y la convención de conteo de días.
• El método de costo efectivo detrás de la divulgación de costo.
• El registro de topes que guarda los límites regulados de tasas y cargos.
• Las divulgaciones que el mercado exige.
• El pipeline de desembolso que corre dentro de la transacción de desembolso.
• El validador de productos y la extensión de previsualización de cronograma.
• Las políticas de actor que deciden quién puede aprobar y quién puede desembolsar.

Los perfiles se compilan dentro del servicio en lugar de configurarse en tiempo de ejecución. Hoy vienen dos: BR para Brasil, y XX, una base genérica sin impuestos y sin topes. La tabla de jurisdicciones en la base de datos es una proyección de lo que trae el servicio, así que ninguna llamada de API crea una jurisdicción. Consulta Jurisdicciones.

​

Cómo se resuelve un request

---

Cada request pasa por las mismas tres puertas antes de que corra un handler. Vincula cada tenant a una jurisdicción antes de que envíe tráfico. Lender rechaza un request de un tenant sin vínculo.

​

El dinero sale por el outbox

---

Lender nunca contabiliza en el ledger durante tu request. La ruta tiene cuatro propiedades que vale conocer:

1. Un desembolso, un devengo de interés y una cotización de prepago brasileña liquidada escriben cada uno una intención de posting en la misma transacción de base de datos que la fila del negocio. Un crash entre las dos no es posible.
2. Un dispatcher lee la intención del outbox y la releva a Midaz.
3. Cada intención lleva una clave de idempotencia determinista, así que un relay reintentado colapsa en una sola transacción del ledger.
4. El routing falla cerrado. Un posting se contabiliza en la organización y el ledger que resuelve el perfil contable, y un despliegue single-tenant puede caer a su default configurado. Cuando no resuelve ningún destino, Lender no contabiliza nada.

Configura el endpoint del ledger y sus credenciales antes de esperar contabilizaciones. Hasta que resuelvan, las intenciones esperan en el outbox y nada llega al ledger. Lender en la plataforma cubre la ruta completa, incluido lo que aporta el perfil contable.

​

Qué expone el servicio

---

Lee la referencia de health y readiness para el contrato de probes compartido entre los productos de Lerian.

​

Almacenes

---

Configuración y despliegue lista los ajustes detrás de cada uno.

​

Trabajo por tiempo

---

No todo empieza con un request. La ejecución de devengo también corre como job programado. Cada job queda apagado hasta que lo habilitas, y tú defines su horario. Consulta Contabilidad y ejecuciones de devengo.

​

Próximos pasos

---