Saltar al contenido principal

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.

Multi-tenancy permite que un solo despliegue sirva a múltiples clientes independientes — llamados tenants — con aislamiento completo de datos entre ellos. Cada tenant opera como si tuviera su propio entorno dedicado, aunque la infraestructura subyacente sea compartida. En Lerian, multi-tenancy está disponible en despliegues SaaS (siempre activo) y BYOC Multi-Tenant.

​
Cómo funciona

El aislamiento de tenants se aplica a nivel de aplicación a través de tu token de autenticación.
  1. Te autentificas vía Access Manager y recibes un JWT.
  2. Ese token incluye un claim tenantId que identifica tu tenant.
  3. En cada solicitud de API, la plataforma resuelve tu tenant a partir del token automáticamente.
  4. Todas las operaciones — crear organizaciones, consultar ledgers, registrar transacciones — se limitan a tu tenant.
Nunca envías un identificador de tenant en headers ni en el cuerpo de la solicitud. El token se encarga de ello.
Multi-tenancy es transparente a nivel de API. Tu código de integración es el mismo ya sea que ejecutes single-tenant o multi-tenant — la única diferencia es que los despliegues multi-tenant requieren autenticación en cada solicitud.

​
Relación entre tenant y organización

Un tenant no es lo mismo que una organización. Un solo tenant puede crear y gestionar múltiples organizaciones — por ejemplo, para representar subsidiarias, sucursales regionales o diferentes unidades de negocio. 
Tenant (resuelto desde JWT)
├── Organización A
│   ├── Ledger 1
│   └── Ledger 2
├── Organización B
│   └── Ledger 3
Cuando listas organizaciones, solo ves las que pertenecen a tu tenant. Lo mismo aplica para cada recurso en la plataforma — ledgers, cuentas, transacciones y balances se limitan a tu tenant automáticamente.

​
Aislamiento de datos

Los datos de cada tenant están aislados a nivel de base de datos. Cada tenant opera en una base de datos separada, lo que significa:
  • Los datos de diferentes tenants nunca se almacenan juntos.
  • Las consultas de un tenant no pueden alcanzar los datos de otro tenant.
  • Incluso si dos tenants crean estructuras organizativas idénticas, sus datos permanecen completamente separados.
Este aislamiento se aplica mediante middleware que enruta cada solicitud a la base de datos correcta basándose en el claim tenantId de tu JWT. No hay forma de eludir esto a través de la API.
Los operadores BYOC pueden elegir entre aislamiento a nivel de base de datos o a nivel de esquema según sus requisitos de infraestructura.

​
Lo que esto significa para ti

​
Si eres cliente SaaS

Nada cambia en cómo usas la API. Autentícate, obtén tu token y realiza solicitudes. La plataforma gestiona el aislamiento de forma transparente. No necesitas gestionar identificadores de tenant ni preocuparte por fugas de datos entre clientes.

​
Si eres operador BYOC ejecutando multi-tenant

Tú configuras qué tenants existen y cómo se aprovisionan sus bases de datos. Tus clientes se autentifican a través de Access Manager y reciben tokens con alcance definido. La plataforma enruta cada solicitud a la base de datos correcta del tenant automáticamente.

​
Si ejecutas single-tenant (BYOC o desarrollo local)

Multi-tenancy está deshabilitado por defecto. Tu configuración existente sigue funcionando sin cambios. No se requiere un claim de tenant en el JWT, y la autenticación puede ser opcional dependiendo de tu configuración.

​
Configuración (operadores BYOC)

Multi-tenancy está deshabilitado por defecto. Para habilitarlo, configura MULTI_TENANT_ENABLED=true en el entorno del ledger (y del CRM, si aplica). Una vez habilitado, la plataforma requiere un servicio Tenant Manager en ejecución y autenticación en cada solicitud.

​
Configuraciones principales

Estas variables aplican tanto al Ledger como al componente CRM:
VariableDescripciónPredeterminado
MULTI_TENANT_ENABLEDHabilita el modo multi-tenant. Cuando es false, la plataforma se ejecuta en modo single-tenant.false
MULTI_TENANT_URLURL del servicio Tenant Manager. Requerido cuando multi-tenant está habilitado.—
MULTI_TENANT_SERVICE_API_KEYAPI key para autenticarse con el Tenant Manager. Requerido cuando multi-tenant está habilitado.—
MULTI_TENANT_CONNECTIONS_CHECK_INTERVAL_SECFrecuencia (segundos) con la que la plataforma revalida las configuraciones de tenants contra el Tenant Manager.—
MULTI_TENANT_CACHE_TTL_SECCuánto tiempo (segundos) se cachea localmente la configuración de un tenant antes de re-consultarla. Usa 0 para deshabilitar el caché.120

​
Circuit breaker del Tenant Manager

Protege contra interrupciones del Tenant Manager fallando rápido cuando el servicio no está disponible:
VariableDescripciónPredeterminado
MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLDFallas consecutivas antes de que el circuito se abra.5
MULTI_TENANT_CIRCUIT_BREAKER_TIMEOUT_SECCuánto tiempo (segundos) el circuito permanece abierto antes de reintentar.30

​
Caché en Redis

El modo multi-tenant usa Redis para cachear las configuraciones de tenants entre instancias:
VariableDescripciónPredeterminado
MULTI_TENANT_REDIS_HOSTHostname del servidor Redis.—
MULTI_TENANT_REDIS_PORTPuerto del servidor Redis.6379
MULTI_TENANT_REDIS_PASSWORDContraseña de autenticación de Redis.—
MULTI_TENANT_REDIS_TLSHabilita TLS para la conexión con Redis.false

​
Configuraciones específicas del CRM

Estas variables solo están disponibles en el componente CRM y controlan el comportamiento del pool de conexiones para las conexiones de base de datos multi-tenant:
VariableDescripciónPredeterminado
MULTI_TENANT_TIMEOUTTimeout (segundos) del cliente HTTP para las solicitudes al Tenant Manager.30
MULTI_TENANT_MAX_TENANT_POOLSNúmero máximo de pools de conexión a base de datos concurrentes (uno por tenant activo).100
MULTI_TENANT_IDLE_TIMEOUT_SECCuánto tiempo (segundos) antes de que un pool de conexiones de tenant inactivo sea evictado.300
Para la mayoría de los deployments, los valores predeterminados funcionan bien. Ajusta CACHE_TTL_SEC y CONNECTIONS_CHECK_INTERVAL_SEC según la frecuencia con la que agregas o modificas tenants — valores más bajos significan propagación más rápida de los cambios de tenants, valores más altos reducen la carga sobre el Tenant Manager.
MULTI_TENANT_ENABLED=true requiere PLUGIN_AUTH_ENABLED=true. La autenticación debe estar activa para que el aislamiento de tenants funcione — la plataforma resuelve los tenants desde el claim del JWT.

​
Páginas relacionadas

Modelos de despliegue

Comprende las diferencias entre SaaS, BYOC Single-Tenant y BYOC Multi-Tenant.

Seguridad

Conoce las garantías de aislamiento de tenants y el modelo de responsabilidad compartida.

Access Manager

Comprende cómo funcionan la autenticación y la resolución de tenants basada en JWT.

Organizaciones

Aprende cómo se estructuran las organizaciones dentro de un tenant.