Arquitectura multi-tenant: 3 decisiones que marcan el resto del proyecto.

1. Qué significa realmente "multi-tenant"

Un SaaS multi-tenant sirve a múltiples clientes (tenants) desde una misma base de código y, normalmente, una misma infraestructura. La pregunta interesante no es "¿lo somos?". Es ¿cómo aislamos los datos entre tenants?. Las opciones, de menos a más aislamiento:

1. Shared schema con columna tenant_id en cada tabla.
2. Schema por tenant dentro de la misma base de datos.
3. Base de datos por tenant (database-per-tenant).
4. Infraestructura dedicada por tenant (single-tenant deployment).

Cada opción tiene consecuencias operativas, de coste y de seguridad radicalmente distintas. Y el trade-off no es lineal: a veces la opción "barata" acaba siendo la más cara al llegar al primer cliente enterprise.

Decisión 1 · ¿Qué nivel de aislamiento necesitas?

Responder esto bien exige pensar en el cliente futuro, no en el primero. Concretamente:

• ¿Van a pedir backup/restore independiente por cliente?
• ¿Hay sectores regulados (salud, finanzas) en tu target que exijan aislamiento lógico o físico por contrato?
• ¿Vais a vender a empresas que tengan compliance interno exigiendo que sus datos no compartan servidor con un competidor?
• ¿Necesitas restaurar el estado de un tenant sin afectar al resto?

Si 3 de 4 son sí, el shared-schema no aguanta. Vete a schema-per-tenant o DB-per-tenant desde el minuto uno. La migración desde shared-schema es técnicamente posible pero costosa (mover millones de filas, reescribir queries, parar el sistema en la migración).

Si 0 de 4, el shared-schema es la opción obvia: más barato, más simple, más rápido. Y para el 70% de los SaaS B2B es perfectamente suficiente.

Decisión 2 · ¿Cómo vas a prevenir fugas cross-tenant?

En shared-schema la mayoría de incidentes de seguridad en SaaS vienen de aquí: una query olvida el WHERE tenant_id = ? y un cliente ve datos de otro. Es catastrófico — legal, reputación y churn.

La solución NO es "tener cuidado al escribir queries". Es hacer que sea técnicamente imposible olvidarlo. Tres capas que debes montar el primer día:

1. Query scoping por defecto: Eloquent global scopes, repositorios con filtro forzado, o sentencias parametrizadas que ocultan el query builder raw.
2. Tests automatizados de aislamiento: un test que crea 2 tenants, pobla datos en ambos, y verifica que NO hay leak en ningún endpoint. Debe correr en CI en cada PR.
3. Row-level security a nivel DB: en PostgreSQL, policies RLS con current_setting('app.tenant_id'). La DB rechaza cualquier SELECT que no establezca el tenant activo. Red de seguridad definitiva.

Sin estas 3 capas, cuando un desarrollador nuevo se incorpore y escriba una query ad-hoc, el leak está a una línea de distancia.

Decisión 3 · ¿Cómo harás migrations con 200+ tenants?

Este es el que siempre se olvida y siempre duele. En shared-schema no hay problema: migras una vez. En schema-per-tenant o DB-per-tenant, cada migration hay que aplicarla 200 veces. Cosas que se rompen:

• El deploy dura 45 minutos en vez de 30 segundos.
• Si a la migration 87 falla, algunos tenants están migrados y otros no. El código nuevo rompe para los no-migrados.
• Down time imposible de planificar si la empresa atiende 24/7.

Solución: desde el día uno, diseña las migrations para zero-downtime (siempre backward-compatible, desplegar código nuevo con DB vieja antes de la migration). Y automatiza el orquestador de migrations per-tenant con checkpoints y resumable. Hazlo la segunda semana del proyecto, no cuando tengas 200 tenants y un susto.

Resumen decisional

Tres preguntas para hacerte en la primera semana:

1. ¿Qué nivel de aislamiento necesitan tus clientes futuros?
2. ¿Cómo vas a imposibilitar fugas cross-tenant (scoping + tests + RLS)?
3. ¿Cómo vas a hacer migrations cuando tengas 200 tenants y operación 24/7?

Si las tres tienen respuesta clara, la arquitectura es sólida y el resto del proyecto escalará sin sorpresas. Si alguna es "ya lo veremos", apunta el tecnicismo para los primeros 18 meses y prepárate para pagarlo con intereses.