Saltar al contenido principal
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.

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