> ## 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 está construido Lender: cinco dominios, el perfil de jurisdicción que aporta cada regla de mercado, el pipeline de solicitudes y el outbox que lleva el dinero al ledger. Lender es un solo servicio. Dentro de él, cinco dominios son dueños del recorrido de crédito, un **perfil** de jurisdicción aporta cada regla específica del mercado y el dinero llega al ledger por una cola durable en lugar de una llamada en línea. ## Cinco dominios, un servicio *** | Dominio | Qué le pertenece | Dónde se detiene | | ------------------ | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | **Productos** | Productos de préstamo, versiones de producto, plantillas de cargo, tablas de tasa flotante. | Una versión nunca cambia. Términos nuevos son una versión nueva. | | **Originación** | 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. | | **Administración** | La cuenta de préstamo activa: versiones de cronograma, pagos, pagos anticipados, reprogramaciones, correcciones. | Nunca edita el historial. Una corrección es una transacción nueva. | | **Contabilidad** | Perfiles contables, reglas de asiento, intenciones de asiento, ejecuciones de devengo, referencias de diario. | Construye asientos balanceados. El relay los entrega. | | **Auditoría** | 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 cuenta de préstamo** es la clave que los une. Lender no acuña ese identificador. Lo aportas cuando desembolsas, y desde entonces cada dominio identifica el préstamo con él. ## La unión de jurisdicción *** Las reglas de crédito cambian según el mercado, así que ningún dominio nombra un mercado. Todo lo específico de un 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 tasa y de comisión. * Las divulgaciones que exige el mercado. * El pipeline de desembolso que corre dentro de la transacción de desembolso. * El validador de producto y la extensión de vista previa del 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 lleva el servicio, así que ninguna llamada de API crea una jurisdicción. Consulta [Jurisdicciones](/es/products/lender/jurisdictions). ## Cómo se resuelve una solicitud *** Cada solicitud pasa por las mismas tres compuertas antes de que corra un handler. Lender espera un bearer JWT. Las dos lecturas de descubrimiento de jurisdicción 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 un llamador no puede elegir un tenant. Lender lee el vínculo de jurisdicción del tenant y pone el perfil correspondiente en el contexto de la solicitud. La búsqueda se guarda en cache durante cinco minutos, así un nuevo vínculo surte efecto dentro de esa ventana. Vincula cada tenant a una jurisdicción antes de que envíe tráfico. Lender rechaza una solicitud de un tenant sin vínculo. ## El dinero sale por el outbox *** Lender nunca asienta en el ledger durante tu solicitud. La ruta tiene cuatro propiedades: 1. Un desembolso, un devengo de intereses y una cotización de pago anticipado brasileña liquidada escriben cada uno una **intención de asiento** en la misma transacción de base de datos que la fila de negocio. Una caída entre las dos no es posible. 2. Un despachador lee la intención del outbox y la transmite a Midaz. 3. Cada intención lleva una clave de idempotencia determinista, así un relay reintentado colapsa en una sola transacción de ledger. 4. El enrutamiento falla en modo cerrado. Un asiento se contabiliza en la organización y el ledger que resuelve el perfil contable, y un despliegue single-tenant puede recurrir a su valor predeterminado configurado. Cuando no se resuelve ningún destino, Lender no asienta nada. Configura el endpoint del ledger y sus credenciales antes de esperar contabilizaciones. Hasta que se resuelvan, las intenciones esperan en el outbox y nada llega al ledger. [Lender en la plataforma](/es/products/lender/lender-in-the-platform) cubre la ruta completa, incluido lo que el perfil contable aporta a ella. ## Lo que 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 metadatos de 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 la configuración en tiempo de ejecución. | Lee la [referencia de health y readiness](/es/reference/health-and-readiness) para el contrato de sondas que comparten los productos Lerian. ## Almacenes *** | Dependencia | Rol | | -------------- | -------------------------------------------------------------------------------------------------------- | | PostgreSQL | Cada tabla de dominio, y el outbox. Aplican dos conjuntos de migración: el conjunto core y el de Brasil. | | Valkey o Redis | Registros de idempotencia, y la cache de jurisdicción. | | RedPanda | Eventos de ciclo de vida, cuando el streaming está habilitado. | | Midaz | El destino de cada asiento. | [Configuración y despliegue](/es/products/lender/configuration-and-deploy) lista los ajustes detrás de cada uno. ## Trabajo dirigido por el tiempo *** No todo empieza con una solicitud. La ejecución de devengo también corre como un job programado. Cada job permanece apagado hasta que lo habilitas, y tú defines su programación. Consulta [Contabilidad y ejecuciones de devengo](/es/products/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 asiento, el catálogo de eventos y el aislamiento de tenants. Dependencias, el contenedor y los ajustes que dan forma a un despliegue.