Multi-tenant: Cómo una sola infraestructura sirve a 10 clientes sin que sus datos se mezclen

Hay un momento en la vida de todo emprendedor tecnológico que define si su negocio será un servicio de consultoría caro o una empresa escalable. Es el momento en que tiene que decidir si construye una infraestructura separada para cada cliente o si diseña una sola infraestructura que sirva a todos.

La primera opción es intuitivamente segura. Cada cliente tiene su servidor, su base de datos, su aplicación. No hay riesgo de que los datos se mezclen. No hay posibilidad de que un error en el sistema de un cliente afecte a otro. Es limpio, predecible y completamente insostenible después del tercer cliente.

La segunda opción es contraintuitiva pero económicamente inevitable. Una sola infraestructura. Múltiples clientes. Separación lógica --no física-- de los datos. Es lo que la industria llama multi-tenancy. Y es, en nuestra experiencia construyendo Davix Growth, no solo una decisión de arquitectura sino la decisión que determina si tu modelo de negocio funciona o no.

Este artículo explica cómo funciona la arquitectura multi-tenant de Davix Growth, por qué cada decisión técnica tiene un impacto directo en la economía del negocio, y cómo puedes aplicar los mismos principios si estás construyendo un servicio de IA para múltiples clientes en América Latina.

El problema de la infraestructura dedicada

Empecemos por la aritmética.

Si ofreces un servicio de IA operativa a clínicas --como nosotros-- y cada cliente necesita su propia infraestructura completa, los costos se multiplican linealmente. Un servidor para el cliente A. Otro servidor para el cliente B. Una base de datos para cada uno. Una instancia de tu aplicación para cada uno. Licencias separadas de cada componente del stack.

Con los servicios que usamos --Chatwoot para mensajería, Frappe cómo CRM, Dify para orquestación de agentes, almacenamiento, APIs de modelos de lenguaje-- el costo de infraestructura dedicada por cliente sería aproximadamente S/180-220 mensuales. Si cobras S/149 al mes por el servicio Growth, pierdes dinero con cada cliente que agregas.

Ese es el escenario catastrófico: un negocio donde crecer te empobrece.

La arquitectura multi-tenant resuelve esto de raíz. Los costos de infraestructura base se comparten. Y el costo marginal de agregar un nuevo cliente baja dramáticamente porque lo que agregas no es un nuevo servidor sino una nueva configuración dentro del servidor existente.

Nuestros números reales: infraestructura base compartida S/272 mensuales. Eso cubre hasta 10 clientes. El costo marginal por cliente adicional --el costo real de agregar uno más-- es cercano a S/8-12, básicamente el consumo incremental de API del modelo de lenguaje.

Breakeven: 2 clientes. A S/149 cada uno, eso es S/298 de ingreso contra S/272 de costo. Margen positivo desde el segundo cliente.

Con 10 clientes: MRR S/1,490, costos S/272, margen bruto 82%.

Esos números son posibles exclusivamente porque la arquitectura es multi-tenant. No hay otra forma de llegar a 82% de margen con precios accesibles para PyMEs latinoamericanas.

La arquitectura: cuatro componentes, un guardián

Davix Growth tiene cuatro componentes principales que interactúan para servir a cada cliente. Cada componente maneja la multi-tenancy de forma diferente, pero todos responden a un mismo principio: separación lógica total con infraestructura física compartida.

Componente 1: Chatwoot -- Una bandeja por cliente

Chatwoot es la plataforma de mensajería que recibe los mensajes de WhatsApp de los pacientes. En una arquitectura de instancia única, cada cliente tiene su propia bandeja de entrada (inbox) dentro de la misma instalación de Chatwoot.

Cada inbox tiene un identificador único: el inbox_id. Cuando un paciente de Face Clinic escribe por WhatsApp, el mensaje llega a la bandeja con inbox_id = 12. Cuando un paciente de otra clínica escribe, su mensaje llega a inbox_id = 15. Mismo Chatwoot. Misma base de datos. Bandejas completamente separadas.

Los agentes humanos de Face Clinic solo ven la bandeja de Face Clinic. Los de la otra clínica solo ven la suya. No hay posibilidad de que un operador de un cliente vea las conversaciones de otro. Chatwoot maneja esto nativamente con su sistema de roles y permisos.

Componente 2: Dify -- Una aplicación por cliente

Dify es la plataforma de orquestación de agentes de IA. Aquí es donde se configuran los flujos de conversación, las herramientas que el agente puede usar, los prompts que definen su comportamiento, y las conexiones a APIs externas.

Cada cliente tiene su propia aplicación Dify con su propia app_api_key. La aplicación de Face Clinic tiene prompts específicos para cirugía estética facial, precios de blefaroplastia, protocolo de preparación pre-quirúrgica. La aplicación de otro cliente --digamos, una clínica dental-- tiene prompts completamente diferentes, precios diferentes, protocolos diferentes.

Mismo servidor Dify. Aplicaciones independientes. Cada una con su propia clave API que funciona cómo candado: solo quien tiene la clave correcta puede activar la aplicación correcta.

Componente 3: Frappe/ERPNext -- Un sitio por cliente

Frappe es el framework sobre el que corre ERPNext (o en nuestro caso, ERPx). Frappe tiene una capacidad nativa de multi-tenancy que es particularmente elegante: cada cliente opera en su propio "site" dentro de la misma instalación.

Cada site tiene su propia base de datos, su propia URL, su propia configuración. Face Clinic tiene faceclinic.erpx.pe. Otro cliente tiene otraclínica.erpx.pe. Misma instalación de Frappe. Bases de datos completamente separadas.