Arquitectura multitenant: qué es, modelos y cuándo conviene

Una arquitectura multitenant (o multiinquilino) es aquella en la que una sola instancia de una aplicación atiende a muchos clientes distintos, manteniendo los datos de cada uno separados e invisibles para los demás.

Es el modelo sobre el que funciona prácticamente todo el software en la nube que usas. Cuando contratas una herramienta de gestión y entras a tu panel, no estás usando una copia exclusiva para ti: compartes el mismo sistema con miles de empresas, cada una viendo solo lo suyo.

La analogía que lo explica

Un edificio de apartamentos frente a casas independientes.

En el edificio (multitenant) todos comparten estructura, ascensor, tuberías y mantenimiento. Cada familia tiene su piso con su llave y no puede entrar en el de al lado. Es más barato por vecino y el mantenimiento se hace una vez para todos.

En las casas independientes (single-tenant), cada familia tiene su estructura completa. Más control y más privacidad, pero también mucho más caro y hay que reparar el tejado casa por casa.

El término "tenant" (inquilino) viene justamente de ahí: cada cliente es un inquilino del mismo sistema.

Los tres modelos de aislamiento de datos

La decisión técnica central es cómo se separan los datos de cada cliente. Hay tres enfoques y cada uno tiene su precio.

1. Base de datos compartida, esquema compartido

Todos los clientes en las mismas tablas, con una columna tenant_id que indica a quién pertenece cada fila.

SELECT * FROM pedidos WHERE tenant_id = 42;

A favor: el más barato y el más simple de mantener. Una sola migración actualiza a todos los clientes.

En contra: el aislamiento depende enteramente del código. Una sola consulta donde se olvide el filtro y un cliente ve los datos de otro. Es el riesgo real de este modelo, y ocurre más de lo que se cuenta.

Cuándo usarlo: muchos clientes pequeños, datos poco sensibles, presupuesto ajustado.

2. Base de datos compartida, esquema separado

Un esquema por cliente dentro del mismo servidor de base de datos. Las tablas están separadas pero comparten instancia.

A favor: mejor aislamiento sin multiplicar la infraestructura. Permite hacer copias de seguridad por cliente.

En contra: cada migración hay que aplicarla a cada esquema. Con quinientos clientes, eso es un proceso que hay que automatizar sí o sí.

3. Base de datos independiente por cliente

Cada cliente, su propia base de datos.

A favor: aislamiento máximo, restauración individual sencilla, y facilita cumplir normativas que exigen separación física de datos.

En contra: el más caro y el más complejo de operar.

Cuándo usarlo: pocos clientes grandes, sectores regulados como salud o banca, o cuando el cliente lo exige por contrato.

Comparativa

Por qué se usa tanto

Coste. Un servidor que atiende a mil clientes cuesta muchísimo menos que mil servidores. Es lo que permite vender software por 20 dólares al mes.

Mantenimiento. Se corrige un fallo una vez y queda arreglado para todos. En single-tenant habría que desplegar cliente por cliente.

Aprovechamiento de recursos. No todos los clientes usan el sistema a la vez. Compartir infraestructura aprovecha los huecos.

Incorporar clientes nuevos. Dar de alta uno más es crear un registro, no montar un entorno.

Los problemas reales y cómo se resuelven

El vecino ruidoso

Un cliente que lanza consultas pesadas puede degradar el servicio de todos los demás. Se mitiga con límites de uso por cliente, colas de procesos pesados y monitorización por inquilino para detectar quién consume de más.

Fugas entre clientes

El riesgo más grave. Basta con que un desarrollador olvide el filtro de tenant_id en una consulta.

Cómo se previene de verdad: no confiando en que nadie lo olvide. Las defensas que funcionan son estructurales:

• Aplicar el filtro en una capa central por la que pase toda consulta, no en cada consulta suelta.
• Usar seguridad a nivel de fila en la propia base de datos, para que la restricción se aplique aunque el código falle.
• Tests automáticos que comprueben explícitamente que un cliente no puede acceder a datos de otro.
• Revisión obligatoria de cualquier consulta nueva que toque datos de cliente.

Personalización limitada

Si cada cliente pide funciones distintas, el código se llena de excepciones. Se resuelve con configuración por cliente y activación de funciones, no con ramas de código separadas.

Copias de seguridad y restauración

Con tablas compartidas, restaurar los datos de un solo cliente sin afectar a los demás es una operación delicada. Conviene tener el procedimiento resuelto y probado antes de necesitarlo.

Cómo se identifica al cliente

En cada petición hay que saber de qué inquilino se trata. Las formas habituales:

• Subdominio: cliente.miapp.com. La más extendida.
• Dominio propio: app.sucliente.com, apuntando a tu servidor.
• Ruta: miapp.com/cliente/panel. Simple pero menos elegante.
• Desde la sesión: tras iniciar sesión, el identificador viaja en el token.

Lo importante no es cuál elijas, sino que ese identificador se resuelva una sola vez, al inicio de la petición, y que el resto del sistema lo use sin volver a calcularlo.

Preguntas frecuentes

¿Multitenant es lo mismo que SaaS?
No, aunque van casi siempre juntos. SaaS es el modelo de negocio; multitenant es la arquitectura que suele hacerlo rentable.

¿Es seguro compartir base de datos entre clientes?
Puede serlo, si el aislamiento está garantizado por la arquitectura y no por la disciplina de cada desarrollador.

¿Se puede migrar de single-tenant a multitenant?
Sí, pero es costoso: hay que añadir el identificador de inquilino a todo el modelo de datos y revisar cada consulta. Mejor decidirlo al principio.

¿Se pueden combinar modelos?
Sí, y es habitual: tabla compartida para los planes básicos y base de datos dedicada para los clientes grandes que lo exigen.

---

¿Te interesa el desarrollo de aplicaciones? En nuestro catálogo de cursos técnicos tienes formación desde cero, con acceso inmediato y de por vida.