Arquitectura Multi-Tenant para SaaS: Conceptos y Decisiones

La arquitectura multi-tenant permite atender a varias organizaciones con una misma plataforma, manteniendo los datos y los permisos de cada cliente aislados. La decisión central no es solo dónde se almacenan los datos. Es cómo el contexto del tenant acompaña la identidad, consultas, archivos, colas, caché, registros y tareas administrativas sin abrir caminos de acceso cruzado.

Respuesta directa: ¿qué modelo elegir?

Utiliza el modelo pool cuando la eficiencia y la operación compartida son prioritarias y el dominio acepta políticas granulares bien probadas. Utiliza silo cuando el aislamiento, los requisitos contractuales o el riesgo justifican recursos dedicados. El modelo bridge combina elementos: por ejemplo, aplicación compartida con esquema o base de datos separada. La elección puede variar según el plan o la sensibilidad del cliente.

AWS destaca que la autenticación y autorización de función no son suficientes para el aislamiento. Un usuario puede estar autenticado y autorizado para usar una funcionalidad, pero aún así acceder a recursos de otro tenant si el contexto organizacional no se aplica en cada operación.

Modele identidad y pertenencia primero

Separe usuario de organización. Una persona puede pertenecer a más de un tenant y tener un rol diferente en cada uno. Un modelo común incluye organizations, memberships, roles y las entidades del dominio con organization_id. El tenant activo debe ser resuelto en el servidor a partir de una asociación válida, nunca aceptado solo de un campo enviado por el navegador.

Los tokens pueden cargar contexto, pero los cambios de asociación y la revocación deben ser considerados. Para operaciones sensibles, confirme la pertenencia actual en el servidor o en la base de datos. Las claves administrativas no deben ser expuestas al cliente.

RLS como defensa en profundidad

En PostgreSQL/Supabase, Row Level Security aplica políticas a cada acceso a la tabla. La documentación oficial recomienda habilitar RLS en tablas de esquemas expuestos. En una aplicación multi-tenant, las políticas normalmente relacionan la fila al tenant y verifican la asociación del usuario.

RLS no sustituye el diseño de API, validación o pruebas. Crea una barrera adicional en caso de que una consulta olvide un filtro. Los índices en las columnas utilizadas por las políticas son importantes para evitar que la seguridad se convierta en un cuello de botella. Las operaciones con service_role o privilegios que ignoran RLS requieren caminos separados, registros y revisión más rigurosa.

El contexto necesita atravesar toda la arquitectura

• Base de datos: todas las entidades pertenecientes al cliente tienen clave de tenant.
• Almacenamiento: caminos y políticas incluyen organización, no solo usuario.
• Caché: la clave contiene tenant y permisos relevantes.
• Colas: cada mensaje registra tenant e identidad de la operación.
• Búsqueda: índices y filtros preservan el límite organizacional.
• Registros: tenant aparece para investigación, sin exponer datos indebidos.
• Métricas: consumo es atribuido al tenant para costo y límites.
• Administración: acciones privilegiadas tienen motivo, actor y pista de auditoría.

Una filtración puede ocurrir fuera de la base de datos. Un caché compartido con clave incompleta o un trabajo asíncrono sin contexto puede devolver datos correctos al cliente equivocado.

Estrategia de pruebas

Crea al menos dos tenants en pruebas automatizadas. Para cada consulta y mutación, prueba el acceso permitido y también la negación cruzada. Prueba listados, búsqueda por ID conocido, actualización, eliminación, archivos, exportaciones, trabajos y rutas administrativas.

Incluye escenarios de cambio de tenant, invitación revocada, usuario sin asociación, IDs manipulados y intento de usar recurso creado por otra organización. En RLS, prueba las políticas directamente en la base de datos con roles equivalentes a los de la aplicación. Las copias de seguridad y la restauración también deben preservar la pertenencia.

Cuándo migrar de pool a bridge o silo

No migres solo por crecimiento abstracto. Busca señales: requisitos contractuales, residencia de datos, clientes con carga desproporcionada, necesidad de ventana propia, recuperación aislada o personalización que amenaza el modelo compartido. Diseña desde temprano identificadores y automatización de aprovisionamiento que permitan mover un tenant sin reescribir el dominio.

Checklist de revisión

• Tenant explícito en las entidades, archivos, colas y cachés.
• Pertenencia validada en el servidor y en la base de datos.
• RLS habilitada y probada en las tablas expuestas.
• Índices compatibles con filtros y políticas.
• Ninguna clave privilegiada en el navegador.
• Pruebas negativas entre dos o más tenants.
• Registros de acciones administrativas y cambios críticos.
• Métricas y límites por organización.
• Copia de seguridad y restauración probadas.
• Plan documentado para mover o aislar tenants.

Fuentes primarias

• AWS: Estrategias de Aislamiento de Tenants en SaaS
• AWS: Aislamiento de tenants en SaaS
• AWS: Guía para Arquitecturas Multi-Tenant
• Supabase: Row Level Security

Consulta también las precauciones de seguridad y LGPD en SaaS y nuestro enfoque de desarrollo de plataformas SaaS.