Diagrama de arquitectura SaaS multi-tenant: modelos silo, pool y puente

Dibuja un producto SaaS multi-tenant como la mayoría de los equipos dibujan cualquier sistema y se verá exactamente igual que uno de un solo inquilino: una puerta de enlace, algunos servicios, una base de datos. La propiedad más importante del sistema, qué datos de qué cliente pueden acabar dónde, no aparece por ninguna parte. Y, sin embargo, esa propiedad condiciona las decisiones más difíciles: cómo se aíslan los inquilinos (tenants), cómo se atiende a los clientes grandes, cómo funciona el onboarding y qué puede romper un vecino ruidoso (noisy neighbor).

Esta guía muestra cómo hacer visible la multitenencia en un diagrama de arquitectura: el vocabulario, qué mostrar, los modelos silo, pool y puente (bridge), y un ejemplo con recursos compartidos y dedicados.

El vocabulario

Estos términos son habituales en los textos sobre arquitectura SaaS, incluidas las guías de SaaS de AWS:

• Inquilino (tenant). Una organización cliente, con sus propios usuarios y datos.
• Plano de control (control plane). Servicios que gestionan a los inquilinos en lugar de servir el producto: onboarding, registro de inquilinos (tenant registry), identidad, medición del uso y facturación.
• Plano de aplicación (application plane). El producto en sí: los servicios y almacenes de datos que los inquilinos usan a diario.
• Contexto del inquilino (tenant context). El ID del inquilino que viaja con cada petición, normalmente como un claim del token de acceso.
• Silo. Recursos dedicados a un solo inquilino, como una base de datos aparte o un stack completo.
• Pool. Recursos compartidos por muchos inquilinos, separados por políticas y por el ID del inquilino.
• Puente (bridge). Una mezcla de ambos: por ejemplo, cómputo compartido con bases de datos dedicadas para algunos inquilinos.

Qué tiene que mostrar el diagrama

1. De dónde viene el contexto del inquilino. El proveedor de identidad y el claim del token que lleva el ID del inquilino.
2. Dónde se impone el aislamiento. No "en el código", sino en un lugar concreto: una política de seguridad a nivel de fila (row-level security), un esquema por inquilino, una base de datos aparte, una política de IAM.
3. Qué recursos son compartidos y cuáles dedicados. Etiqueta cada almacén de datos y cada servicio como pool o silo.
4. Cómo encuentra una petición sus recursos. El enrutamiento o la búsqueda (lookup) que envía a un inquilino a la base de datos o al stack que le corresponde.
5. Cómo se crean los inquilinos. El flujo de onboarding que escribe en el registro y aprovisiona los recursos dedicados que hagan falta.

Silo, pool y puente

Modelo	Qué se comparte	Ventajas	Costos
Silo	Nada en el plano de aplicación	Aislamiento fuerte, ajuste por inquilino, respuestas de cumplimiento más sencillas	Mayor costo por inquilino, más despliegues que operar
Pool	Cómputo y datos, separados por el ID del inquilino	Bajo costo por inquilino, un solo despliegue	El aislamiento depende de cada consulta y cada política; vecinos ruidosos
Puente	Algunas capas compartidas y otras dedicadas	Inviertes en aislamiento donde importa	Dos caminos que construir, probar y dibujar

Muchos productos empiezan con un pool y más adelante trasladan a silos a sus clientes más grandes o más regulados, lo que convierte el sistema en un puente. El diagrama debe dejar clara esa división.

El ejemplo: inquilinos en pool y un silo empresarial

Un producto de analítica B2B tiene cientos de inquilinos estándar y un cliente empresarial, Globex, que exige su propia base de datos:

• Los usuarios inician sesión a través de un proveedor de identidad que reconoce a los inquilinos. Su token de acceso lleva tenant_id.
• La puerta de enlace de API valida el token y pasa el contexto del inquilino a la API de analítica.
• La API de analítica busca el nivel (tier) y la base de datos del inquilino en el registro de inquilinos.
• Los inquilinos estándar comparten una base de datos PostgreSQL en pool, donde la seguridad a nivel de fila filtra cada consulta por tenant_id.
• Globex tiene una base de datos dedicada, aprovisionada por el servicio de onboarding cuando se creó el inquilino.

Dos marcos separan el plano de control del plano de aplicación, y las etiquetas de los almacenes de datos indican qué modelo de aislamiento se aplica. Ahora un revisor puede hacer las preguntas correctas: ¿qué pasa si el registro se cae y quién puede cambiar el nivel de un inquilino?

Reglas para diagramas multi-tenant

Dibuja niveles, no inquilinos

Nunca dibujes una caja por cliente. Dibuja un camino por nivel o modelo de despliegue y nombra un inquilino de ejemplo si ayuda, como Globex más arriba.

Etiqueta el contexto del inquilino en las conexiones

Escribe cómo se identifica al inquilino en cada salto: JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Los trabajos en segundo plano y los consumidores de eventos también necesitan el contexto del inquilino, y es ahí donde más a menudo se pierde.

Muestra dónde se impone el aislamiento

"Aislado por ID de inquilino" es una promesa; una política de seguridad a nivel de fila, un esquema por inquilino o una cuenta aparte es un mecanismo. Escribe el mecanismo en la etiqueta del almacén de datos o añade un nodo Política a su lado.

Muestra los límites por inquilino

Los límites de tasa, las cuotas y los límites de concurrencia por inquilino son la forma en que un sistema en pool protege a los inquilinos entre sí. Anótalos en la puerta de enlace y en los servicios que los aplican.

Mantén la medición y la facturación en el plano de control

Los eventos de uso por inquilino alimentan la medición y la facturación. Dibújalos en el plano de control, para que el plano de aplicación siga centrado en atender peticiones.

Errores comunes

• Sin plano de control. El onboarding, el registro de inquilinos y la identidad son parte central de la arquitectura, no herramientas de administración.
• Aislamiento por convención. Una nota que dice "cada consulta filtra por inquilino" no es un control. Muestra la política que lo impone.
• Enrutamiento invisible. Si algunos inquilinos usan recursos distintos, dibuja la búsqueda que lo decide.
• Rutas asíncronas olvidadas. Las colas, las tareas programadas y las exportaciones de analítica que pierden el ID del inquilino son una fuente clásica de fugas.
• Un diagrama gigante. Mantén la residencia de datos (regiones), el despliegue y la vista lógica en diagramas separados.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos nodos Marco del pack Básico, Control plane y Application plane.
3. Añade dos nodos Caja del pack Básico para los usuarios estándar y los de Globex, un Proveedor de identidad del pack Seguridad, una Puerta de enlace de API del pack Nube y nodos Contenedor del pack Modelo C4 para el servicio de onboarding y la API de analítica.
4. Añade nodos Postgres del pack Datos para el registro de inquilinos, la base de datos en pool y la dedicada, con el modelo de aislamiento en la etiqueta.
5. Etiqueta las conexiones con el contexto del inquilino y haz discontinua la conexión de aprovisionamiento.

El ejemplo usa 11 nodos de diagrama, dentro del plan Free. Para la capa de nube y de red que hay debajo, consulta el diagrama de VPC de AWS y la página del caso de uso cloud.

Preguntas frecuentes

¿Qué modelo de aislamiento debo elegir? Parte de los requisitos de tus clientes y de tu costo por inquilino. El pool es el más barato de operar, el silo es el más fácil de explicar a un revisor de seguridad y el puente te permite ofrecer ambos. Escribe el motivo en el diagrama.

¿Cómo muestro cientos de inquilinos? No lo haces. Muestra cada nivel o modelo de despliegue una vez y deja la lista de inquilinos en el registro, que es donde debe estar.

¿Necesita cada inquilino su propio diagrama? No. Un diagrama por arquitectura, con los niveles en él. Un inquilino empresarial en silo puede tener su propio diagrama de despliegue si se ejecuta en una cuenta o región aparte.

¿Cómo muestro la residencia de datos? Con marcos de región en un diagrama de despliegue aparte, cada uno con los stacks o bases de datos de los inquilinos que deben quedarse allí.

¿Dónde van las claves de cifrado por inquilino? Junto a los almacenes de datos que protegen, como un nodo del pack Seguridad o una nota, con el servicio de gestión de claves que las guarda.

Empieza gratis — un puesto, sin tarjeta de crédito.