> ## 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. # Arquitectura de Lender > Las partes con las que Lender está construido: cinco dominios, el perfil de jurisdicción que aporta cada regla de mercado, el pipeline de request y el outbox que lleva el dinero al ledger. 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 *** | Dominio | De qué es dueño | Dónde se detiene | | --------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | **Products** | Productos de préstamo, versiones del producto, plantillas de cargos, tablas de tasa flotante. | Una versión nunca cambia. Términos nuevos son una versión nueva. | | **Origination** | El ciclo de vida de la solicitud, y el cronograma que produce el desembolso. | Registra la intención de contabilizar. No escribe en el ledger. | | **Servicing** | La cuenta de préstamo activa: versiones de cronograma, repagos, prepagos, reprogramaciones, correcciones. | Nunca edita el historial. Una corrección es una transacción nueva. | | **Accounting** | Perfiles contables, reglas de posting, intenciones de posting, ejecuciones de devengo, referencias de asiento. | Construye postings balanceados. El relay los entrega. | | **Audit** | El rastro de lo que le pasó a una cuenta de préstamo. | Solo agrega. Nada reescribe un evento. | 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](/es/lender/jurisdictions). ## Cómo se resuelve un request *** Cada request pasa por las mismas tres puertas antes de que corra un handler. Lender espera un JWT bearer. Las dos lecturas de descubrimiento de jurisdicciones son las únicas operaciones públicas. El tenant viene de la identidad validada. Nunca es un header, un campo del body ni un parámetro de ruta, así que quien llama no puede elegir un tenant. Lender lee el vínculo de jurisdicción del tenant y pone el perfil correspondiente en el contexto del request. La búsqueda se cachea por cinco minutos, así que un cambio de vínculo toma efecto dentro de esa ventana. 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](/es/lender/lender-in-the-platform) cubre la ruta completa, incluido lo que aporta el perfil contable. ## Qué expone el servicio *** | Superficie | Propósito | | -------------------------------- | ------------------------------------------------------------------------------------------------------- | | `/api/v1/...` | Toda la API del producto, descrita por un solo documento OpenAPI. | | `/health`, `/readyz`, `/version` | Liveness, readiness de dependencias y metadata del build. Los tres responden antes de la autenticación. | | `/api/v1/streaming/manifest` | El catálogo de eventos que publica este despliegue. | | `/api/v1/systemplane/...` | Administración de configuración en tiempo de ejecución. | Lee la [referencia de health y readiness](/es/reference/health-and-readiness) para el contrato de probes compartido entre los productos de Lerian. ## Almacenes *** | Dependencia | Rol | | -------------- | ------------------------------------------------------------------------------------------------------- | | PostgreSQL | Todas las tablas de dominio, y el outbox. Aplican dos conjuntos de migraciones: el core y el de Brasil. | | Valkey o Redis | Registros de idempotencia, y el caché de jurisdicción. | | RedPanda | Eventos de ciclo de vida, cuando el streaming está habilitado. | | Midaz | El destino de cada posting. | [Configuración y despliegue](/es/lender/configuration-and-deploy) 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](/es/lender/accounting-and-accrual-runs). ## Próximos pasos *** Una solicitud desde enviada hasta desembolsada, y la transacción que hace el trabajo. El vocabulario que comparte todo el producto. La ruta de posting, el catálogo de eventos y el aislamiento de tenants. Dependencias, el contenedor y los ajustes que moldean un despliegue.