¿Qué es la arquitectura multi-tenant?

La arquitectura multi-tenant es el diseño que hace económicamente posible el software como servicio. En lugar de levantar una copia separada de la aplicación para cada cliente, un solo despliegue los atiende a todos, y la separación entre ellos se impone por software. La ruta de actualización, la carga operativa y el costo por cliente mejoran drásticamente. La contrapartida es que el aislamiento se convierte en una propiedad que hay que construir y defender, no en algo que el hardware le da gratis.

En una plataforma de contact center lo que está en juego es especialmente alto, porque los datos implicados son grabaciones de llamadas, listas de contactos de clientes, registros de consentimiento y listas de supresión. Un BPO que opera clientes competidores en una sola plataforma tiene la obligación contractual, y a menudo regulatoria, de mantenerlos separados, y una fuga no es un inconveniente sino un incidente.

Dónde debe imponerse el aislamiento

La implementación común más débil pone el límite en el código de la aplicación: cada consulta filtra por tenant, y que funcione bien depende de que cada desarrollador se acuerde cada vez. Funciona hasta que una consulta no lo hace, y nada revela el error hasta que alguien ve datos que no debería. El enfoque más sólido lleva la aplicación del límite a la base de datos, de modo que la política va unida a los datos y no al código que los lee, y una consulta que omite el filtro de tenant no devuelve nada en lugar de devolverlo todo. Al evaluar una plataforma, la pregunta útil no es si los tenants están aislados, sino en qué capa.

Qué debe variar por tenant

• Datos y usuarios. Campañas, contactos, grabaciones y cuentas, acotados para que un usuario solo exista dentro de su tenant.
• Configuración de cumplimiento. Listas de supresión, horarios de llamada y reglas de consentimiento, ya que los tenants operan bajo regímenes distintos.
• Retención. Retención de grabaciones y transcripciones según la política propia de cada tenant, con retención legal (legal hold) disponible.
• Números. Una identidad de llamante que pertenece exclusivamente a un tenant, y un rango de extensiones que no choca con el de otro.
• Marca e idioma. La interfaz que ven los usuarios de cada tenant, incluido su idioma predeterminado.
• Facturación y medición. Uso atribuible a cada tenant, no agrupado en un solo total.

Cómo implementa DialerBee la arquitectura multi-tenant

El arquitectura multi-tenant ofrece a cada tenant datos aislados mediante la seguridad a nivel de fila de PostgreSQL en la capa de base de datos; reglas de cumplimiento independientes que cubren listas de No Llamar, horarios de llamada y seguimiento del consentimiento; grabaciones separadas con almacenamiento por tenant; retención y legal hold independientes; facturación por tenant que registra por separado el uso, los minutos y los puestos; control de acceso basado en roles que limita a agentes y supervisores a su tenant; ajuste de IA por tenant, y alta de tenants en minutos desde el portal de administración o la API. Está disponible en 11 idiomas, con idioma predeterminado por tenant.

El límite se mantiene en el resto de la plataforma en lugar de quedarse en la base de datos. Cada panel e informe de analítica está acotado al tenant actual, así que los clientes de un BPO solo ven sus propios datos mientras los dueños de la plataforma pueden acceder a analítica entre tenants, y los límites entre tenants se imponen en la capa de base de datos. La propiedad de cada identificador de llamante es exclusiva de un tenant, lo que impide que un número del que usted responde aparezca en las llamadas de otro, y cada tenant tiene sus propios pools de identificadores de llamante con reglas de rotación e informes aislados. Los datos de transcripción se almacenan con aislamiento por tenant mediante seguridad a nivel de fila, con retención configurable por tenant. En los despliegues de marca blanca , el administrador del socio es dueño de los tenants que crea, y el asistente de alta asigna a cada tenant su propio rango de extensiones y sus propios identificadores de llamante, porque los valores predeterminados chocan y una troncal compartida no es un identificador de llamante.

Preguntas frecuentes

¿Cuál es la diferencia entre multi-tenant y single-tenant?

En un despliegue single-tenant, cada cliente tiene su propia instancia del software y a menudo su propia infraestructura. En un despliegue multi-tenant, los clientes comparten la infraestructura y el código, y están separados por la aplicación y la base de datos, no por tener copias separadas. Multi-tenant es más barato de operar y de actualizar; single-tenant da separación física a un costo por cliente mucho mayor.

¿Qué es la seguridad a nivel de fila?

Una función de base de datos que asocia una política a una tabla para que una consulta solo pueda devolver las filas que el tenant actual tiene derecho a ver. Importa porque la alternativa, filtrar por tenant en cada consulta que hace la aplicación, depende de que cada desarrollador se acuerde cada vez. Imponerla en la capa de base de datos significa que una consulta que olvida el filtro no devuelve nada en lugar de devolverlo todo.

¿Multi-tenant significa que mis datos se mezclan con los de otros clientes?

Significa que se almacenan en una infraestructura compartida con límites impuestos, no que otra persona pueda acceder a ellos. La pregunta práctica para un proveedor no es si las tablas se comparten, sino dónde se impone el aislamiento. Un aislamiento implementado solo en el código de la aplicación es una respuesta más débil que uno impuesto por la base de datos.

¿Por qué cada tenant necesita su propio rango de extensiones e identificadores de llamante?

Porque los valores predeterminados chocan. Dos tenants dados de alta con el mismo rango de extensiones o apuntados a la misma troncal producen llamadas mal enrutadas e identidades de llamante que pertenecen a la empresa equivocada. Dar a cada tenant su propio rango y sus propios números en el momento del alta evita un tipo de problema que es desagradable de diagnosticar después.

¿Qué debe ser configurable por tenant?

Todo lo que difiere entre las empresas que usan la plataforma, que en un contact center es casi todo: reglas de cumplimiento, horarios de llamada, listas de supresión, periodos de retención, idioma predeterminado, marca, números y facturación. Un ajuste que solo puede ser global es un ajuste que tarde o temprano estará mal para alguien.

Términos relacionados: plataforma de contact center de marca blanca, contact center BPO, gestión del consentimiento, caller ID y presencia local y DID.