Tenancy

Compartir y separar entre contextos

Tenancy examina cómo el sistema comparte o separa acceso, estado, capacidad y recursos entre contextos de clientes o tenants. La pregunta práctica es: tenant de qué, qué comparte con otros y en qué frontera se aplica la separación.

Un tenant es un contexto lógico que el producto trata como unidad para datos, configuración, acceso o servicio. Puede representar una organización cliente, cuenta, workspace, suscripción, institución o cliente de negocio. La equivalencia concreta debe declararse; no la determina el nombre de una tabla ni un identificador cloud.

Krebs, Momm y Kounev estudian grupos de usuarios de un cliente y distinguen niveles de recursos compartidos y preocupaciones arquitectónicas. Su definición está situada en SaaS; aquí usamos Tenancy como eje para examinar explícitamente esas fronteras, sin imponer una implementación única. Architectural Concerns in Multi-Tenant SaaS Applications, 2012.

Pertenece a architecture-decision-axes. Single-tenant y multi-tenant no son perfiles equivalentes a monolith o microservices: expresan decisiones de sharing que pueden combinarse con ambos y con modular-monolith, service-based-architecture o service-oriented-architecture.

Tenant no es User

User identifica un actor: persona, identidad técnica o servicio que actúa sobre el sistema. Tenant identifica el contexto lógico cliente al que pertenecen ciertos datos, configuraciones o recursos. Un tenant puede contener muchos usuarios; un usuario puede participar en varios tenants si el producto lo admite.

En Commerce SaaS, Tenant A es una empresa comerciante y Tenant B otra. Una operadora puede administrar ambos, con permisos distintos. Autenticarse como esa operadora no indica por sí solo sobre qué empresa debe ejecutar Place Order.

Tampoco todos los datos tienen necesariamente un tenant: un catálogo público compartido o configuración del proveedor puede tener otro alcance. Debe quedar claro cuándo se trabaja en contexto de cliente y cuándo existe una operación transversal autorizada. «Siempre hay un tenant» sin definir excepciones también puede producir confusión.

Single-tenant, multi-tenant y combinaciones

Single-tenant describe una frontera dedicada a un tenant, por ejemplo una instancia de aplicación o base. Puede facilitar atribución, cambios particulares y contención de ciertos efectos. Introduce capacidad duplicada, operación de una flota, upgrades repetidos y posible baja utilización.

Multi-tenant describe una frontera compartida por varios tenants. Puede mejorar utilización y permitir operaciones comunes, con obligaciones adicionales para acceso, partición de datos, interferencia y configuración. Compartir runtime no significa que deban compartir todas las representaciones ni una única unidad de deployment.

El alcance importa: una aplicación dedicada puede usar infraestructura de storage compartida; un producto multi-tenant puede repartir clientes entre varios deployments. Single-tenant no significa ausencia de todo recurso común. Multi-tenant tampoco significa una sola instancia de toda la solución.

Hay mixed tenancy: runtime compartido, datos particionados por tenant y storage dedicado para determinados clientes. Otra combinación utiliza administración compartida y entornos de procesamiento dedicados. La guía de Azure presenta modelos con distintos grados de sharing por componentes; sirve para comparar ejemplos, no como definición universal. Tenancy models.

No existe una superioridad general. Una instalación dedicada puede satisfacer una necesidad de ciclo de vida propio y resultar costosa para numerosos clientes pequeños. Compartir puede simplificar upgrades y ampliar el alcance de un defecto.

Qué fronteras se deciden

La tabla propone preguntas para una arquitectura concreta, no una taxonomía exhaustiva:

Dimensión	Pregunta de Tenancy
Identity/context	¿Cómo se selecciona y verifica el contexto?
Datos	¿Qué representación pertenece a qué tenant?
Compute	¿Qué cargas comparten ejecución?
Memoria y recursos	¿Qué pools o límites se comparten?
Configuración	¿Qué políticas varían entre tenants?
Red	¿Qué accesos y destinos están separados?
Deployment	¿Qué clientes comparten actualizaciones?
Operación	¿Qué se observa, suspende o migra por tenant?
Costo	¿Cómo se atribuye capacidad y consumo?

Estas preguntas no convierten Tenancy en toda la arquitectura. Su foco es la relación de sharing entre contextos. deployment examina unidades instalables, execution-model cómo vive el trabajo e isolation la contención de efectos que la elección debe sostener.

Tenancy, Isolation y autoridad

Dos tenants pueden tener filas separadas y compartir CPU o conexiones. También pueden compartir un proceso con controles efectivos de acceso a sus datos. Tenant isolation es una aplicación de Isolation; las palabras no son sinónimos.

Una base dedicada no evita que una credencial o un routing incorrecto accedan a la base de otro cliente. Una base compartida no demuestra inseguridad automáticamente: deben examinarse controles y rutas reales. Autenticación, autorización y enforcement del contexto son obligaciones críticas, pero multi-tenancy no define por sí sola un modelo de autorización.

data-ownership responde otra pregunta. Un pedido puede pertenecer al contexto Tenant A, mientras Orders tiene autoridad para definir y modificar su ciclo de vida. Tenant A no es una unidad arquitectónica autorizada automáticamente a escribir cualquier representación interna.

Confundir contexto con autoridad hace que el identificador del cliente parezca suficiente para validar todo cambio. Inventory todavía debe controlar reservas y Payments autorizaciones, aunque ambos estados estén asociados a la misma empresa.

Partición de datos: opciones y límites

Un shared schema con tenant key distingue registros dentro de estructuras comunes. Schema per tenant separa estructuras dentro de un motor. Database per tenant permite separar bases; deployment per tenant separa otra frontera, posiblemente incluyendo aplicación y datos.

Estas opciones cambian migraciones, configuración, overhead, recuperación y blast-radius. No son peldaños de madurez ni garantías equivalentes. Un schema separado puede compartir servidor y capacidad; una clave de tenant no controla por sí sola todos los caminos de acceso.

En Commerce, consultar un order ID necesita respetar el contexto permitido, incluso si los IDs son globalmente únicos. La propiedad «este pedido existe» no demuestra «este actor puede usarlo». Copias, caches y procesos administrativos deben conservar el mismo significado del contexto.

El diseño debe identificar qué se recupera o migra individualmente y qué operación afecta al conjunto. Una base compartida puede dificultar una restauración selectiva; bases dedicadas multiplican operaciones de actualización. La decisión requiere necesidades reales y costos conocidos.

Propagar el contexto más allá del request

El contexto puede acompañar requests, mensajes, background jobs, operaciones de storage, claves de cache y registros de auditoría. Debe seleccionarse desde información confiable y validarse según el contrato; transportar un campo tenantId no vuelve confiable lo que un caller afirma.

Place Order para Tenant A
  → Orders: pedido en contexto A
  → Payments: trabajo diferido en contexto A
  → Inventory: reserva en contexto A
  → Shipping: solicitud en contexto A

Si PaymentSettlement pierde ese contexto, puede usar credenciales, configuración o atribución de capacidad equivocadas. Un cache key sin ámbito suficiente puede devolver información de otro cliente. Son consecuencias arquitectónicas de la frontera, sin exigir aquí un patrón de implementación concreto.

coordination sigue conduciendo el resultado entre capacidades; Tenancy añade el contexto en que ese resultado debe ser legal. Cambiar de modelo de ejecución no debe borrar esa obligación.

Noisy neighbor y capacidad compartida

Noisy neighbor describe una carga de un tenant que consume capacidad compartida y perjudica otros. scaling examina cómo cambiar esa capacidad y qué límites compartidos permanecen; repartir clientes no garantiza repartir su demanda. En nuestro ejemplo, Tenant A lanza reporting intensivo y Tenant B experimenta esperas en Orders porque comparten conexiones o I/O.

rate-limiting limita solicitudes según una política; admission-control decide qué trabajo se acepta. Cuotas y particiones pueden proteger capacidad, sin demostrar que todos los recursos queden aislados. Los mecanismos se desarrollan en sus canonicals; aquí interesa a qué contexto aplican y qué protege cada frontera.

Una cuota por request puede ignorar jobs diferidos más costosos. Atribuir solo tráfico HTTP puede ocultar quién ocupa workers o storage. Conviene identificar consumo compartido relevante antes de prometer que un tenant no afectará otro.

Configuración y ciclo de vida

Branding, features, políticas e integraciones pueden variar por cliente. Multi-tenancy no exige código personalizado por tenant. Configuración delimitada puede conservar un producto común; variantes libres aumentan combinaciones de pruebas, diagnóstico y riesgo de cambios.

Provisionar, activar, suspender, migrar o eliminar un tenant implica más que autorización durante un request. Suspender nuevos pedidos no necesariamente cancela liquidaciones o envíos pendientes. La política necesita distinguir nuevas admisiones, obligaciones existentes y retención requerida por el producto.

Un upgrade compartido afecta varios clientes; un cliente dedicado puede tener una ventana propia y conservar dependencias comunes. operability necesita identificar contexto y variante. cost-efficiency debe incluir capacidad ociosa, mantenimiento y atribución, además del precio unitario de compute.

Decisión ilustrativa en Commerce SaaS

Tenant A y Tenant B comparten aplicación; Tenant C usa storage dedicado por una necesidad acordada. Orders, Payments, Inventory y Shipping conservan sus responsabilidades. Datos y configuración se asocian al contexto pertinente sin otorgar autoridad semántica al tenant.

La revisión pregunta qué comparte C todavía, cómo se enruta trabajo diferido y si migrarlo exige detener otros tenants. También examina si un batch de A puede ocupar recursos de B y cómo reconocer esa interferencia.

Es un ejemplo de decisión, no un Quality Attribute Scenario ni un diseño universal. Relaciona Tenancy con deployment, ejecución, autoridad y aislamiento sin colapsarlos. scaling estudia demanda y capacidad, sin reducir la decisión a añadir réplicas.