Multitenancy en SaaS: silo, pool o bridge — y el camino entre los modelos

La decisión más cara antes del primer cliente

En una plataforma SaaS, el modelo de tenencia es el punto donde se cruzan la economía unitaria, la postura de seguridad y la velocidad de ingeniería. Determina lo que cuesta servir a cada cliente, hasta dónde se propaga un incidente, lo que puede prometerle a un auditor y lo dolorosa que será cada migración futura. Los equipos dedican semanas a elegir el framework de frontend y una tarde al modelo de tenencia. Las proporciones deberían invertirse: los frameworks se sustituyen; los modelos de tenencia se calcifican.

Tres modelos canónicos cubren el espacio — silo, pool y bridge — y ninguno es simplemente el mejor. Cada uno intercambia aislamiento por coste operativo. La pregunta útil no es qué modelo es el correcto, sino qué compromisos puede permitirse hoy su negocio — y cuánto costará cambiar de opinión más adelante.

Silo, pool, bridge: los verdaderos compromisos

Los modelos difieren en lo que comparten y en lo que dedican; cada modo de fallo se deriva de esa elección.

• Silo — cada tenant recibe recursos dedicados, normalmente una base de datos y a menudo también cómputo. El aislamiento más fuerte y el relato de cumplimiento más simple — pero un suelo de coste fijo por tenant y un problema de flota: doscientos tenants son doscientas bases de datos que migrar, respaldar, parchear y monitorizar.
• Pool — todos los tenants comparten la infraestructura, separados por un tenant_id. El coste marginal por tenant tiende a cero, pero el aislamiento pasa a ser responsabilidad de la aplicación y una sola consulta mal escrita puede degradar a todos a la vez.
• Bridge — cómputo compartido sobre datos separados (esquema o base de datos por tenant), o una flota por niveles: infraestructura compartida para el plan estándar y silos dedicados para los tenants regulados o enterprise.

Para productos B2B, nuestra opción por defecto es un modelo pool detrás de una abstracción de tenencia estricta, con el silo vendido como nivel premium con precio propio, nunca adoptado por reflejo. La infraestructura dedicada que nadie paga no es arquitectura: es un subsidio.

El aislamiento es defensa en capas, no una cláusula WHERE

Una columna tenant_id más la disciplina de los desarrolladores no es una estrategia de aislamiento; basta un filtro olvidado para acabar notificando una brecha de datos. El aislamiento debe resistir incluso cuando un desarrollador se equivoca — impóngalo en varias capas independientes.

• Resuelva el contexto del tenant una sola vez en el borde — subdominio, token o cabecera — y propáguelo por cada petición, job y evento; nada aguas abajo debe volver a derivarlo.
• Haga que las consultas entre tenants sean imposibles de escribir por accidente: repositorios o query builders que exijan el ámbito del tenant por construcción, no por convención.
• Active la row-level security en la base de datos como red de seguridad: un filtro omitido hace fallar la consulta en lugar de filtrar un conjunto de datos.
• Cifre los campos regulados con claves por tenant, de modo que el offboarding y las solicitudes de borrado sean operaciones sobre claves, no recorridos de tablas.
• Mantenga una suite automatizada de pruebas de acceso entre tenants; cualquier fallo en ella es un incidente de seguridad, no un ticket de bug.

Noisy neighbors: un problema de equidad, no de capacidad

En un modelo pool la capacidad es compartida; sin reglas de equidad explícitas, el tenant más grande fija la latencia de todos los demás, y más hardware solo eleva el techo de un planificador injusto. Mida el consumo por tenant desde el primer día: un puñado de tenants genera la mayor parte de la carga, y no se puede gobernar lo que no se atribuye.

• Imponga límites de tasa y cuotas por tenant en la capa de API, incorporados al precio de los planes, para que los límites sean una palanca comercial y no una disculpa.
• Limite la concurrencia por tenant en las colas en segundo plano — la importación masiva de un tenant nunca debe retrasar los webhooks de otro.
• Establezca timeouts de sentencia y dirija las consultas analíticas a réplicas; la ruta transaccional nunca es el lugar para el reporting.
• A escala de flota, la arquitectura en celdas y el shuffle sharding acotan el radio de impacto de las sobrecargas y de los fallos de despliegue.

Observabilidad que sabe decir la palabra tenant

La primera pregunta en cualquier incidente SaaS es: ¿quién está afectado? Si su telemetría no puede responderla en segundos, tiene dashboards, no observabilidad. Convierta la identidad del tenant en una dimensión de primera clase en logs, trazas y métricas, y gestione la cardinalidad con criterio: fidelidad completa en logs y trazas, top N más agregados en las métricas.

Defina SLO por tenant al menos para su nivel más alto y mida el consumo de forma continua. Los mismos datos responden a las preguntas de soporte en minutos, alimentan el pricing por uso y sacan a la luz a los clientes a los que, sin hacer ruido, sirve con pérdidas.

Diseñe la migración antes de necesitarla

Sea cual sea el modelo con el que lance, algún tenant tendrá que moverse tarde o temprano: un contrato enterprise exigirá un silo, o una flota de silos se volverá demasiado cara de operar. La ruta de migración es parte de la arquitectura, no una ocurrencia tardía.

• Conserve el tenant_id en cada fila incluso en las bases de datos en silo — consolidar datos sin él es arqueología.
• Mantenga los esquemas idénticos entre silos; la deriva de esquemas convierte en silencio una migración en una reescritura.
• Enrute a los tenants a través de una abstracción estable que asocie cada tenant con la ubicación de sus datos, de forma que esa ubicación pueda cambiar sin tocar la aplicación.
• Ensaye la mudanza: exportación acotada al tenant, cutover basado en replicación, una breve ventana de doble escritura y un rollback verificado.

El modelo con el que lance no será el modelo con el que se retire. El trabajo de la arquitectura es convertir ese cambio en un proyecto planificado, no en una emergencia para toda la empresa.