Aislamiento que se
puede defender.
Separación de clientes aplicada en la capa de datos y no confiada al código de aplicación, con configuración por cliente y un modelo de acceso que aguanta cuando uno se convierte en doce.
El aislamiento entre clientes aplicado solo en el código de la aplicación funciona hasta la única consulta que olvida el filtro de cliente. Esa consulta se escribirá tarde o temprano, por alguien con prisa, y el modo de fallo es que un cliente vea los datos de otro: la categoría de error que termina contratos en lugar de generar un ticket.
Por eso el aislamiento pertenece a la capa de datos, donde olvidarse no es una opción disponible. Qué mecanismo encaja depende de la forma del producto y de cuánta variación por cliente tenga que absorber, y esa es una decisión de especificación con consecuencias reales, no una preferencia.
Convertir a multiinquilino un esquema que asumía un solo cliente está entre las migraciones más caras que existen. Cada tabla necesita una clave de cliente, cada consulta hay que revisarla, y los datos que ya están en producción hay que asignarlos sin caída de servicio. Si el multiinquilino está plausiblemente en vuestro futuro, decidirlo ahora cuesta una conversación; decidirlo después cuesta un trimestre.
La configuración por cliente es la otra mitad —marca, funciones disponibles, límites, ajustes regionales— construida para que dar de alta un cliente nuevo sea un registro y no un despliegue.
Qué incluye
- Modelo de multiinquilino elegido y documentado con sus contrapartidas
- Aislamiento aplicado en la capa de datos, no solo en la aplicación
- Configuración, marca y activación de funciones por cliente
- Modelo de acceso para usuarios que pertenecen a varios clientes
- Pruebas de aislamiento que fallan de forma ruidosa si se cruza un límite
No incluido
- Mantenimiento continuo salvo contrato aparte
- Licencias de terceros
Kitchen Stocker
Inventario y control de costes multiinquilino para restaurantes, construido y operado por nosotros.
Leer el caso