SaaS multi tenant: qué decidir antes de construir

La multi tenencia es el conjunto de decisiones que son baratas el día uno y caras el día cuatrocientos. La mayoría no son sobre código. Son sobre qué le estás prometiendo a clientes que todavía no conoces.

Esto es lo que hay que decidir por adelantado, y lo que puedes aplazar sin riesgo.

Decide primero el modelo de aislamiento

Modelo	Aislamiento	Costo y esfuerzo	Encaja en
Tablas compartidas con columna de tenant	Lógico, impuesto por software	El más bajo	Casi todo SaaS, sobre todo al principio
Un esquema por tenant	Fuerte, una sola base de datos	Medio. Las migraciones se multiplican	Cientos de tenants con presión de cumplimiento
Una base de datos por tenant	El más fuerte	El más alto. Peso operativo real	Empresa, regulado, o residencia de datos

Empieza con tablas compartidas salvo que un requisito concreto lo prohíba. Es lo más barato de construir, lo más barato de migrar y lo más fácil de razonar. La objeción habitual, que los clientes enterprise exigirán separación física, merece tomarse en serio solo cuando tengas un cliente enterprise preguntándolo. Diseñar para un comprador que no has conocido es como los productos llegan tarde con funciones que nadie pidió.

Lo que sí debes hacer el día uno es hacer explícita la frontera de tenant en todas partes, para que pasar a un modelo más fuerte después sea una migración y no una reescritura.

Haz que filtrar datos sea estructuralmente difícil

Todo bug serio de multi tenencia es el mismo bug: una consulta que olvidó el filtro de tenant. Esto no se resuelve con disciplina, porque la disciplina falla a las 6 de la tarde de un viernes.

Resuélvelo con estructura. Elige una y aplícala sin excepciones:

• Seguridad a nivel de fila en la base de datos. La opción más fuerte. La base de datos se niega a devolver filas de otro tenant aunque la aplicación las pida, así que un filtro olvidado devuelve nada en vez de devolver todo.
• Una capa de repositorio que ninguna consulta pueda saltarse. Toda lectura y escritura pasa por código que inyecta el alcance de tenant desde el contexto de la petición. El cliente crudo no es alcanzable desde el código de funcionalidades.

Después escribe la prueba que importa: crea dos tenants, crea datos en ambos, y verifica que cada endpoint devuelve datos de uno solo. Córrela en CI. Esa única prueba atrapa la clase de bug que termina con empresas.

El tenant no es el usuario

Confundirlos es el error de modelado más común y uno de los más dolorosos de deshacer, porque el arreglo toca todas las tablas.

Los usuarios pertenecen a tenants mediante una membresía, no mediante una columna en el usuario. Una persona puede pertenecer a varias organizaciones con un rol distinto en cada una, y espera conservar un solo acceso. Agencias, consultores, contadores y cualquiera con una matriz necesitan esto, y suelen ser tus mejores clientes.

Construye la tabla de unión el día uno aunque tus primeros cien usuarios pertenezcan cada uno a exactamente un tenant. Cuesta una hora ahora y un trimestre después.

Pon el tenant en el contexto de la petición, una sola vez

Resuelve el tenant en el borde, desde un subdominio, un segmento de ruta o un claim del token, y ponlo en un contexto por petición que la capa de datos lea automáticamente.

Pasar un id de tenant como argumento por cada función es como acaba perdiéndose, normalmente en un trabajo en segundo plano o en un manejador de webhook donde el contexto de petición no existe. Esos dos sitios merecen una auditoría específica: son donde más se olvida el alcance de tenant, porque no hay nadie con sesión iniciada.

Decide pronto la cuestión del vecino ruidoso

Sobre infraestructura compartida un tenant puede degradar el servicio para todos: una importación masiva, un reporte desbocado, una integración reintentando en bucle.

Limita el ritmo por tenant y no por usuario, y pon el trabajo pesado en una cola con límites de concurrencia por tenant. Las dos cosas son mucho más fáciles de añadir antes de tener tráfico que durante el incidente, y el incidente es como la mayoría de equipos descubre que las necesitaba.

Qué puedes aplazar sin riesgo

No todo hay que decidirlo ahora. Esto puede esperar, y aplazarlo es la decisión correcta:

• Personalización por tenant. Temas, campos a medida, flujos configurables. Espera a que lo pidan y construye la versión estrecha.
• Residencia regional de datos. Trabajo real, pero solo cuando exista un cliente con ese requisito.
• Respaldo y restauración por tenant. Hará falta en algún momento. No antes de tener tenants que valga la pena restaurar.
• Facturación por uso. Empieza por licencias o tarifa plana. La medición es un proyecto aparte.

La consola de administración no es opcional

Vas a necesitar responder "¿qué ve este cliente exactamente?" en tu segundo ticket de soporte. Construye una consola que permita a tu equipo ver el estado de un tenant y, con cuidado, suplantar a un usuario dentro de él con la acción registrada.

Esto se recorta del alcance constantemente y es la razón por la que los fundadores terminan consultando producción a mano a medianoche. Es el mismo argumento que en nuestro desglose del costo de un MVP: barato ahora, ruinoso después.

Preguntas frecuentes

Por dónde empezar

Escribe la prueba de aislamiento con dos tenants antes de escribir la segunda funcionalidad. Toma una tarde y es lo único de esta página que evita una categoría de fallo de la que no puedes salir pidiendo perdón.

Si ya estás en producción y no sabes si esa prueba pasaría, cuéntanos tu montaje y te decimos dónde mirar primero.