Software Architecture
Explica modelos de aislamiento multi-tenant para identidad, datos, cómputo, caché, archivos, jobs, observabilidad y personalización en productos SaaS.
Multi-tenancy no es una columna añadida al final del modelo. Es la capacidad de compartir producto e infraestructura sin mezclar autoridad, datos, configuración, rendimiento ni operación entre clientes.
Un sistema multi-tenant atiende múltiples organizaciones mediante una plataforma común. Compartir reduce costo y facilita evolución, pero introduce una responsabilidad crítica: cada operación debe ejecutarse dentro del contexto correcto y respetar límites verificables.
identidad
→ membresía autorizada
→ tenant activo
→ permisos y sucursal
→ operación scoped
→ datos, caché, archivos y eventos scopedEl tenant no es necesariamente una persona ni una sucursal. En DomiSys, el tenant principal puede ser el negocio; las sucursales son divisiones internas con permisos y datos adicionales.
Sin multi-tenancy, cada cliente necesitaría una instalación independiente o el sistema mezclaría datos y configuraciones sin una frontera consistente.
La arquitectura SaaS busca equilibrar:
El reto no es permitir que varios negocios creen pedidos. El reto es garantizar que una operación del negocio A nunca lea, modifique, cachee, publique o restaure información del negocio B.
Filas, documentos, índices, búsquedas, copias, backups y analítica.
Membresías, roles, permisos, sucursales y soporte administrativo.
CPU, memoria, conexiones, colas, workers y límites de concurrencia.
Planes, features, branding, impuestos, monedas, zonas horarias y reglas.
Logs, métricas, incidentes, migraciones, exportaciones, restauraciones y eliminación.
Credenciales, webhooks, proveedores y endpoints configurados por tenant.
Un diseño puede aislar bien la base de datos y fallar mediante una clave de caché global o un job sin contexto.
El cliente puede solicitar trabajar en un tenant, pero no debe otorgarse autoridad a sí mismo.
sesión válida
+ tenant solicitado
+ membresía activa
+ rol y permisos
+ estado del negocio
= TenantContext autorizadoEjemplo:
type TenantContext = {
actorId: string;
businessId: string;
branchIds: string[];
permissions: Set<string>;
plan: string;
};
async function resolveTenantContext(
session: Session,
requestedBusinessId: string,
): Promise<TenantContext> {
const membership = await memberships.findActive({
userId: session.userId,
businessId: requestedBusinessId,
});
if (!membership) throw new ForbiddenError();
return {
actorId: session.userId,
businessId: requestedBusinessId,
branchIds: membership.branchIds,
permissions: membership.permissions,
plan: membership.plan,
};
}La entrada incluye un negocio solicitado, pero el resultado se crea únicamente después de comprobar la membresía. Las capas internas reciben un contexto autorizado, no headers sin validar.
Cada tenant posee una base independiente.
Ventajas:
Costos:
Es apropiado para clientes regulados, grandes o con requisitos contractuales fuertes.
Comparte motor, pero separa objetos lógicos.
Ofrece una frontera visible, aunque el tooling, las migraciones y el número de schemas pueden volverse difíciles de operar. No todos los motores y ORMs lo manejan igual.
Todas las filas incluyen tenant_id.
CREATE TABLE orders (
tenant_id uuid NOT NULL,
order_id uuid NOT NULL,
status text NOT NULL,
total numeric NOT NULL,
PRIMARY KEY (tenant_id, order_id)
);La clave compuesta impide asumir que order_id basta para identificar un recurso dentro del modelo.
Este enfoque suele ser eficiente, pero exige disciplina transversal. Una query sin scope puede convertirse en una fuga masiva.
Tenants pequeños comparten infraestructura; tenants grandes o regulados se asignan a recursos dedicados.
El modelo híbrido introduce routing y operación adicional. El sistema necesita saber dónde vive cada tenant sin filtrar esa decisión por todo el dominio.
Evalúa:
No existe una jerarquía donde “base por tenant” siempre sea superior. El aislamiento más fuerte puede ser inviable si el equipo no puede operar miles de instancias de manera segura.
El tenant debe participar en relaciones que no pueden cruzar límites.
CREATE TABLE order_items (
tenant_id uuid NOT NULL,
order_id uuid NOT NULL,
item_id uuid NOT NULL,
PRIMARY KEY (tenant_id, order_id, item_id),
FOREIGN KEY (tenant_id, order_id)
REFERENCES orders (tenant_id, order_id)
);Una foreign key solo por order_id permitiría relacionar datos de tenants distintos si los IDs no fueran globalmente únicos o si existiera un error de aplicación.
Las restricciones son una defensa adicional, no reemplazan autorización ni repositorios scoped.
Evita APIs internas como:
findOrderById(orderId);Prefiere:
findOrder({ businessId, orderId });Un repositorio que exige tenant hace visible la frontera. Aun así, deben existir pruebas y revisión para queries personalizadas, reportes y migraciones.
Row-Level Security puede añadir protección en motores compatibles. Su valor depende de una configuración correcta, contexto de conexión y cobertura de herramientas administrativas.
La clave debe incluir todas las dimensiones de autorización relevantes:
catalog:v3:{businessId}:{branchId}:{locale}:{permissionsHash}Omitir businessId puede servir datos de otro negocio. Omitir permisos puede revelar precios o capacidades restringidas.
Cada documento debe incluir tenant y los filtros deben aplicarse antes de devolver resultados. Un índice derivado también contiene datos sensibles.
Las rutas y metadata deben incluir ownership. Un nombre impredecible no reemplaza autorización. Las URLs firmadas necesitan alcance y expiración.
business/{businessId}/invoices/{invoiceId}.pdfTodo mensaje debe contener identidad de tenant cuando su efecto dependa de ella.
type OrderConfirmed = {
eventId: string;
businessId: string;
orderId: string;
occurredAt: string;
};El consumidor no debe inferir tenant consultando un recurso global sin scope.
Los jobs programados necesitan:
Un job global que recorre todos los negocios puede permitir que un tenant lento bloquee el progreso de los demás.
Un tenant puede consumir recursos compartidos y degradar a todos.
Se controla con:
Las cuotas deben corresponder al recurso real. Limitar requests no controla necesariamente exportaciones pesadas, almacenamiento o jobs.
Observa:
Evita usar IDs de todos los tenants como labels permanentes en sistemas de métricas con cardinalidad limitada. Para detalle, utiliza logs, trazas o agregaciones controladas.
La configuración de tenant debe ser un modelo explícito, no condicionales dispersos.
plan
→ entitlements
→ límites
→ configuración del negocio
→ configuración de sucursal
→ valor efectivoDiferencia:
No uses un feature flag como autorización permanente.
Los valores necesitan defaults, validación, versionado, auditoría y estrategia de migración.
La arquitectura SaaS puede necesitar medir usuarios, transacciones, almacenamiento o capacidades.
Una medición confiable define:
Facturar directamente desde métricas operativas aproximadas puede producir inconsistencias. El uso comercial suele requerir un ledger o registros durables.
Una migración multi-tenant no debe ser una operación opaca sobre todos los clientes.
Diseña:
Un tenant con datos anómalos no debería detener toda la plataforma.
En tablas compartidas, restaurar un tenant puede requerir extraer filas relacionadas y reconciliar cambios posteriores. Debe diseñarse antes de un incidente.
Necesita autorización, límites, formato estable, seguimiento y protección del archivo generado.
Debe propagarse a datos principales, derivados, cachés, búsquedas, archivos y políticas de backup. “Eliminar una fila” rara vez completa el proceso.
Algunos tenants pueden requerir que datos y backups permanezcan en regiones concretas. Esto afecta routing, almacenamiento, observabilidad y soporte.
El soporte puede necesitar observar el tenant, pero no debe compartir credenciales del cliente.
Una capacidad de impersonation segura incluye:
El flujo recibe businessId, branchId y orderId.
Si cualquier componente omite contexto, el aislamiento se rompe aunque los demás estén correctos.
No basta con probar que un usuario puede consultar sus datos. Debes intentar cruzar fronteras:
Automatiza matrices donde el recurso pertenece al tenant A y la identidad al tenant B. La respuesta no debe revelar si el recurso existe cuando esa información también sea sensible.
Jobs, scripts y consumidores pueden saltarse esa capa. El contexto debe atravesar contratos y persistencia.
El header puede expresar intención, no autoridad.
Búsqueda, cache, analytics y archivos también pueden filtrar información.
Crea forks lógicos imposibles de mantener. Modela configuración y extensiones.
El problema aparece durante el incidente, cuando ya no existe tiempo para inventar una estrategia.
Un cliente grande puede romper supuestos de particionamiento, índices y capacidad. Diseña rutas de promoción a recursos dedicados.
tenant_id no completa un diseño multi-tenant?Testabilidad y estrategia de pruebas arquitectónicas muestra cómo convertir decisiones estructurales, contratos y garantías en evidencia automatizada.