Claves
- La mayoría de los productos B2B deberían empezar con una base compartida y aislamiento a nivel de fila.
- Mover a inquilinos concretos a su propio esquema o base cuando lo exijan el cumplimiento normativo o el tamaño.
- Imponer el contexto de inquilino en la capa de datos, no solo en el código de la aplicación.
- Prever desde el principio exportaciones y copias de seguridad por inquilino.
La multitenencia es una de las decisiones más caras de deshacer en un producto SaaS. Una comparación práctica de los tres modelos habituales y de las señales que deben guiar la elección.
Los tres modelos habituales
Los sistemas multiinquilino suelen usar uno de tres modelos, que equilibran de forma distinta el aislamiento y la carga operativa.
- Base compartida, tablas compartidas: cada fila lleva un identificador de inquilino. El más barato de operar y el más sencillo de desplegar, con el aislamiento más débil por defecto.
- Base compartida, esquema por inquilino: las tablas se duplican por inquilino dentro de una base. Mejor aislamiento, migraciones más complejas.
- Base por inquilino: el aislamiento más fuerte y la copia de seguridad por inquilino más sencilla, con la mayor carga operativa.
Una opción por defecto sensata
Para la mayoría de los productos B2B en fase inicial, tablas compartidas con un identificador de inquilino en cada fila son el punto de partida adecuado. La infraestructura sigue siendo sencilla y las tareas entre inquilinos (facturación, analítica, soporte) siguen siendo fáciles.
El riesgo es una fuga de datos por un filtro olvidado. Afróntelo en la base de datos, no solo en el código: las políticas de seguridad a nivel de fila de PostgreSQL, por ejemplo, pueden obligar a que cada consulta se limite al inquilino actual aunque un desarrollador lo olvide.
Señales que justifican más aislamiento
Un aislamiento más fuerte compensa cuando aparecen ciertas condiciones. Rara vez tiene que aplicarse a todos los inquilinos.
- Un gran cliente exige por contrato almacenamiento dedicado.
- La normativa obliga a guardar los datos en una región concreta.
- El volumen de datos de un inquilino perjudica el rendimiento de los demás.
- Los clientes necesitan copias y restauraciones independientes.
Prever un modelo híbrido
El diseño más práctico a largo plazo admite más de un modelo: la mayoría de los inquilinos comparten infraestructura y unos pocos grandes o regulados tienen su propia base. Solo es posible si la resolución del inquilino ocurre en un único sitio, normalmente una capa de enrutamiento que asocia cada petición con la conexión correcta.
Construya esa capa de enrutamiento pronto, aunque al principio siempre devuelva la misma base. Cuesta poco ahora y ahorra mucho después.
Detalles operativos que importan
La multitenencia no se limita al esquema. La limitación de peticiones, los trabajos en segundo plano, las rutas de almacenamiento de archivos, las cachés y los registros necesitan el contexto de inquilino. También las funciones de cara al cliente, como la exportación de datos y la eliminación de cuentas, que los grandes clientes preguntarán durante la compra.
¿Le ha gustado? Reciba el próximo por correo.