Multi-tenant significa aislar contexto, no solo agregar organization_id
En un SaaS B2B, casi toda operación necesita saber quién actúa y dentro de qué organización. Ese contexto debe llegar a consultas, permisos, integraciones, métricas y acciones de background. Si el aislamiento depende solamente de que la interfaz esconda registros, el diseño es inseguro.
Una arquitectura sólida separa identidad de usuario, membresía de organización y autorización. Un mismo usuario puede pertenecer a más de un workspace con roles diferentes, mientras cada recurso conserva un scope verificable en backend.
- Usuario como identidad global.
- Membresía como relación con una organización.
- Roles y permisos evaluados en backend.
- Filtros de tenant en consultas y jobs.
- Pruebas explícitas de aislamiento entre organizaciones.
El modelo de permisos debe existir antes de crecer
Agregar RBAC al final suele obligar a revisar endpoints, queries y UI. Conviene definir desde el comienzo qué puede hacer owner, admin y member, y qué acciones requieren permisos más específicos. El principio es simple: una acción sensible debe validar autorización donde se ejecuta, no confiar en que el frontend no mostró un botón.
CloserWin y Clyvel usan esta lógica en productos B2B con contexto por organización. La implementación concreta puede variar, pero el criterio de aislamiento se mantiene en todas las capas.
- Permisos por acción, no por pantalla.
- Validación de organización en cada operación sensible.
- Auditoría para cambios administrativos.
- Secrets e integraciones vinculados al tenant correcto.
Background jobs, webhooks y analytics también son multi-tenant
Los errores más sutiles aparecen fuera del request HTTP: un worker procesa una cola sin scope correcto, un webhook no identifica qué organización posee la conexión o una consulta de analytics agrega datos de varios tenants. Por eso el contexto debe viajar con el evento y validarse otra vez al consumirlo.
Las integraciones también deberían pertenecer explícitamente a una organización. Nunca conviene depender de una credencial global si el proveedor opera con cuentas separadas por cliente.
- Tenant ID dentro de eventos y jobs.
- Provider connections por organización.
- Cache keys con scope.
- Métricas y reportes filtrados por tenant.
- Pruebas de workers y webhooks con organizaciones distintas.
Diseñar para evolución: billing, planes y límites
El modelo multi-tenant suele convertirse después en la base de planes, uso, presupuestos y límites. Aunque billing no exista en la primera versión, conviene que la arquitectura pueda medir consumo por organización y asociar capacidades a una suscripción sin reescribir el dominio.
Eso no significa construir un sistema de billing prematuramente. Significa mantener separadas identidad, organización, permisos, uso y configuración para que el producto pueda crecer sin mezclar responsabilidades.
- Medición de uso por organización.
- Entitlements separados de la UI.
- Límites y presupuestos configurables.
- Eventos de billing auditables.
- Migraciones de plan sin alterar datos de negocio.
Preguntas frecuentes
¿Qué es un SaaS multi-tenant?
Un producto donde múltiples organizaciones usan la misma plataforma manteniendo sus usuarios, permisos, datos, configuración e integraciones correctamente aislados.
¿Alcanza con agregar organization_id a las tablas?
No. El aislamiento también debe existir en autorización, consultas, workers, caches, webhooks, analytics e integraciones.
¿Cuándo conviene diseñar roles y permisos?
Desde la primera versión que tenga más de un tipo de usuario o datos sensibles. Agregarlos al final suele producir retrabajo y riesgos de acceso.
Construí el modelo de organización antes de escalar el SaaS
PLAN0101 diseña plataformas B2B con identidad, permisos, datos e integraciones preparados para crecer.
Ver producto digital