Multi-tenant desde el día uno: las decisiones que no se pueden deshacer
Aislamiento de datos, claves foráneas y migraciones: por qué añadir multi-tenancy después cuesta diez veces más.
Escrito por KillaQ
Hay decisiones de arquitectura que se pueden cambiar en una tarde y otras que condicionan el producto durante años. En un SaaS, el modelo de tenancy pertenece al segundo grupo.
El error que parece razonable
"Lancemos con un cliente y añadimos multi-tenancy cuando haga falta." Suena prudente, pero significa que cada tabla nace sin columna de tenant, cada consulta sin filtro, cada clave foránea sin restricción de pertenencia. Cuando llega el segundo cliente, la migración no es añadir una columna: es auditar cada consulta del sistema y demostrar que ninguna cruza la frontera.
Aislamiento: tres modelos
- Fila compartida con discriminador. Una columna
tenantIden cada tabla. Es el modelo más simple de operar y el más barato de escalar. Requiere disciplina absoluta: ninguna consulta puede salir sin filtro. - Esquema por tenant. Aislamiento más fuerte y respaldos independientes, a cambio de migraciones que hay que aplicar N veces.
- Base por tenant. El aislamiento máximo. Solo tiene sentido con pocos clientes grandes o con requisitos regulatorios que lo exijan.
Para la mayoría de productos, la fila compartida es la respuesta correcta — siempre que el filtro no dependa de que el programador se acuerde.
Que el filtro no sea opcional
La diferencia entre un sistema seguro y uno que un día filtra datos entre clientes está en dónde vive el filtro. Si está en cada servicio, es cuestión de tiempo que alguien escriba la consulta que se lo salta.
Ponlo donde no se pueda olvidar: en la capa de acceso a datos, en el contexto de la petición, o directamente en la base con seguridad a nivel de fila. Y añade un test que falle si aparece una consulta sin restricción de tenant.
Las claves foráneas también tienen tenant
Un detalle que se escapa: si Factura pertenece a Cliente y ambos tienen tenantId, la clave foránea debe garantizar que ambos pertenecen al mismo tenant. Sin esa restricción compuesta, un identificador mal validado en un formulario permite adjuntar un registro de un tenant a otro.
Lo que sí puedes dejar para después
No todo tiene que estar el primer día. La facturación por tenant, los planes, los límites de uso y el panel de administración pueden llegar más tarde sin coste estructural. El aislamiento, no.