Toda plataforma SaaS multi-tenant responde a la misma pregunta —¿cómo se mantienen separados los datos de un tenant respecto de los de otro, sobre una única base de código compartida?— pero la respuesta correcta depende del perfil de riesgo de la plataforma. Dos plataformas, Omnitech CRM e IMFlow360, la responden de manera distinta, y ambas respuestas son correctas para lo que cada plataforma necesita.
01Cómo leer este trabajo
Dos estrategias de aislamiento, a grandes rasgos
Las plataformas multi-tenant, en general, aíslan a los tenants en una de unas pocas capas: una base de datos separada por tenant, un esquema separado por tenant, o tablas compartidas delimitadas por un identificador de tenant en la capa de aplicación. Cada opción tiene un costo distinto y un modo de falla distinto; la guía de AWS sobre aislamiento de tenants en SaaS es una referencia pública útil sobre las contrapartidas entre estas estrategias (citada más abajo). Tanto Omnitech CRM como IMFlow360 usan tablas compartidas con aislamiento aplicado en la capa de aplicación, pero lo aplican de manera diferente.
02Cómo leer este trabajo
Omnitech CRM: fallo cerrado en las capas de modelo y de consulta
Omnitech CRM aplica el aislamiento de tenants en las capas de modelo y de consulta, incluido el trabajo en segundo plano en cola, bajo un criterio de fallo cerrado: si a una consulta le falta su alcance de tenant, la solicitud falla en lugar de arriesgar una filtración entre tenants. Un registro central de permisos —126 permisos distribuidos en 22 módulos de negocio— se mantiene deliberadamente separado de esa capa de aislamiento, de modo que los permisos de un rol pueden ampliarse o restringirse sin tocar nunca la ruta de código responsable de mantener a los tenants separados.
03Cómo leer este trabajo
IMFlow360: tenencia basada en filas diferenciada por tipo de negocio
IMFlow360 adopta un enfoque relacionado pero distinto: la multi-tenencia basada en filas delimita cada registro por negocio y sucursal, mientras que un campo business_type —no una base de código bifurcada— diferencia el comportamiento de catálogo, pedidos y flujo de trabajo para negocios de retail, restaurantes, belleza/salón/spa y basados en citas. Los cuatro sectores funcionan sobre un mismo esquema compartido de aproximadamente 146 tablas. El límite de aislamiento sigue el mismo patrón de tablas compartidas que Omnitech CRM; la diferencia es que IMFlow360 usa además ese mismo mecanismo de delimitación para diferenciar el comportamiento de negocio, no solo para separar los datos de los tenants.
04Cómo leer este trabajo
La lección real
La estrategia de aislamiento es una decisión fundacional que se toma una sola vez, tempranamente, según el perfil de riesgo de la plataforma, y es una decisión separada del sistema de permisos que se construye sobre ella. Ambas plataformas aplican el aislamiento en la capa de aplicación sobre tablas compartidas; la diferencia entre una aplicación de fallo cerrado limitada estrictamente a los límites entre tenants, y una delimitación por filas que además conlleva diferenciación de comportamiento por tenant, se reduce a lo que cada plataforma necesitaba que el mecanismo de delimitación hiciera más allá del aislamiento en sí.
