¿Qué Es Multi-Tenancy?
Multi-tenancy es una arquitectura donde una única instancia de software sirve a múltiples clientes (tenants). Los datos de cada tenant están aislados, pero comparten el mismo código, infraestructura y frecuentemente la misma base de datos.
La mayoría de productos SaaS modernos — Slack, Jira, Salesforce, Shopify — son multi-tenant. Como ingeniero QA trabajando en productos SaaS, entender el testing multi-tenant es esencial porque las consecuencias de fallos son severas: filtraciones de datos entre tenants pueden resultar en demandas y penalidades regulatorias.
Patrones de Arquitectura Multi-Tenant
| Patrón | Descripción | Complejidad de Testing |
|---|---|---|
| BD compartida, schema compartido | Todos los tenants en una BD con columna tenant_id | Mayor riesgo |
| BD compartida, schemas separados | Una BD, cada tenant con su propio schema | Riesgo medio |
| Bases de datos separadas | Cada tenant con su propia BD | Menor riesgo |
| Híbrido | Mezcla según tier (free=compartido, enterprise=dedicado) | Complejo |
Áreas Críticas de Testing
Aislamiento de Datos
La categoría de testing más importante. Cada operación de datos debe estar limitada al tenant actual:
Tests a nivel de API:
- Acceder a recursos de otro tenant cambiando IDs en la URL
- Acceder a recursos cambiando el identificador de tenant en headers
- Intentos de SQL injection que podrían saltarse el filtrado por tenant
- Operaciones masivas que podrían incluir datos cross-tenant
Tests a nivel de UI:
- Los resultados de búsqueda solo muestran datos del tenant actual
- Dropdowns y autocomplete solo sugieren items del tenant actual
- Reportes y dashboards solo agregan datos del tenant actual
- Export/download solo incluye datos del tenant actual
Configuración por Tenant
Cada tenant puede personalizar: branding, roles y permisos, workflows, integraciones, campos personalizados.
Verifica que los cambios en la configuración del Tenant A no afecten al Tenant B.
Niveles de Suscripción y Feature Gating
| Funcionalidad | Free | Pro | Enterprise |
|---|---|---|---|
| Usuarios | 5 | 50 | Ilimitados |
| Almacenamiento | 1GB | 50GB | 500GB |
| Acceso API | No | Sí | Sí |
| SSO | No | No | Sí |
| Dominio personalizado | No | Sí | Sí |
Matriz de testing:
- Funcionalidad accesible en el tier correcto
- Funcionalidad bloqueada en tiers inferiores (mensaje apropiado, no un crash)
- Upgrade habilita nuevas funcionalidades inmediatamente
- Downgrade restringe funcionalidades adecuadamente
- Límites aplicados correctamente
Roles de Usuario Dentro de Tenants
| Rol | Permisos Típicos |
|---|---|
| Owner | Control total, facturación, puede eliminar tenant |
| Admin | Gestión de usuarios, configuración, datos |
| Member | Crear y editar contenido propio |
| Viewer | Acceso solo lectura |
| Guest | Acceso limitado a recursos específicos |
Ejercicio: Escenarios de Testing SaaS Multi-Tenant
Estás probando una aplicación SaaS de gestión de proyectos (similar a Jira/Asana) con tres niveles: Free, Pro y Enterprise.
Escenario 1: Testing de Aislamiento de Datos
Crea dos cuentas de tenant: Tenant A (Acme Corp) y Tenant B (Beta Inc).
| Paso | Acción | Resultado Esperado |
|---|---|---|
| 1 | Como Tenant A, crear proyecto “Alpha” | Proyecto visible solo para Tenant A |
| 2 | Como Tenant B, listar todos los proyectos | “Alpha” NO es visible |
| 3 | Como Tenant B, intentar GET /api/projects/{alpha-id} | 404 Not Found (no 403) |
| 4 | Como Tenant A, buscar “Alpha” | Encontrado en resultados |
| 5 | Como Tenant B, buscar “Alpha” | No encontrado |
| 6 | Como Tenant A, exportar todos los proyectos | Export contiene solo proyectos de Tenant A |
Escenario 2: Feature Gating
| Paso | Acción | Resultado Esperado |
|---|---|---|
| 1 | Como Free, intentar habilitar SSO | Prompt “Upgrade a Enterprise” |
| 2 | Como Free, intentar agregar 6to usuario | Prompt “Upgrade a Pro” con mensaje de límite |
| 3 | Como Pro, habilitar dominio personalizado | Funcionalidad disponible |
| 4 | Upgrade de Free a Pro | Nuevas funcionalidades disponibles inmediatamente |
| 5 | Downgrade de Pro a Free | Funcionalidades restringidas, datos preservados |
Escenario 3: Seguridad Cross-Tenant
| Paso | Acción | Resultado Esperado |
|---|---|---|
| 1 | Como admin Tenant A, copiar endpoint de recurso | /api/tenants/a/projects/123 |
| 2 | Como admin Tenant B, llamar ese endpoint | 404 — sin filtración de datos |
| 3 | Como Tenant A, modificar tenant_id en header | Request rechazado |
| 4 | Como usuario deslogueado, acceder a recursos | 401 Unauthorized |
Solución: Bugs Comunes Multi-Tenant
Bug 1: Datos cross-tenant en resultados de búsqueda El índice de búsqueda global no filtraba por tenant_id. Corrección: Agregar filtro tenant_id a todas las consultas de búsqueda.
Bug 2: 403 en lugar de 404 para recursos cross-tenant Retornar 403 en lugar de 404 revela que el recurso existe en otro tenant. Corrección: Siempre retornar 404.
Bug 3: Branding del tenant cacheado entre sesiones Logo y colores del tenant anterior se cacheaban al cambiar. Corrección: Invalidar caché UI al cambiar de tenant.
Bug 4: Bypass de límite de funcionalidades por API El límite de 5 usuarios en Free se aplicaba en UI pero no en API. Corrección: Aplicar límites en capa API/base de datos.
Bug 5: Downgrade no restringía funcionalidades Después de downgrade de Pro a Free, el dominio personalizado permanecía activo. Corrección: Ejecutar verificación de restricción al cambiar de plan.
Estrategia de Testing para Aplicaciones SaaS
Configuración del Entorno de Testing
Mantén al menos tres cuentas de tenant en tu entorno de testing:
- Tenant tier Free — para probar límites y prompts de upgrade
- Tenant tier Pro — para probar funcionalidades de nivel medio
- Tenant tier Enterprise — para probar el conjunto completo
Cada tenant debe tener usuarios en cada rol (Owner, Admin, Member, Viewer).
Puntos Clave
- El aislamiento de datos es la prioridad más alta en aplicaciones multi-tenant — una filtración puede ser catastrófica
- Siempre retorna 404 (no 403) para acceso cross-tenant para prevenir divulgación de información
- El feature gating debe aplicarse en la capa API, no solo en la UI
- Prueba transiciones de nivel de suscripción: upgrades, downgrades y qué pasa con datos y funcionalidades
- Mantén tenants de prueba separados para cada tier con usuarios en cada rol
- Los cambios de configuración en un tenant nunca deben afectar a otro