Separación
El límite lo mantiene la base de datos, no el código
Todos los CRM dicen ser multi-tenant. La afirmación es barata; lo que importa es qué capa sostiene la línea. Si la respuesta es «nuestra aplicación siempre añade el filtro correcto», entonces la garantía vale lo que vale el desarrollador menos descansado que haya escrito alguna vez una consulta.
iKonekt fue multi-tenant desde su primera migración, no adaptado después, lo que suena a presumir y en realidad es una confesión: adaptarlo después es casi imposible de hacer de forma convincente, y todos los que lo han intentado tienen una historia que contar.
La separación vive en la base de datos. Cada una de las veintiséis tablas lleva el tenant al que pertenece, y la política que lo comprueba se ejecuta en cada lectura y cada escritura, por debajo de la aplicación por completo. Una consulta que olvida el límite no devuelve los clientes de otro. No devuelve nada.
Seguridad a nivel de fila, forzada
No es una convención, ni una regla de revisión de código. Es la base de datos la que se niega. Setenta y dos políticas, escritas una a una en lugar de generadas — porque una política generada es una política que nadie ha leído.
Claves compuestas
Un registro hijo referencia a su inquilino y a su padre juntos, como pareja. Un identificador ajeno de otra empresa no se resuelve — simplemente no es una referencia válida.
Ningún inquilino por defecto, nunca
Una petición sin ámbito no se convierte silenciosamente en una petición para el inquilino cero. Lanza un error antes de llegar a la base de datos. No existe un modo «sin ámbito» que puedas olvidar desactivar.
El error que no podía anunciarse
Mientras se hacía el trabajo de multiinquilino, la mayoría de los errores eran ruidosos. Da a dos empresas el mismo dominio de cliente y la base de datos se opone de inmediato, con un código de error y un stack trace; lo arreglas antes de comer.
Uno no se opuso. Una tabla de anulaciones de prompts editables estaba indexada solo por el tipo del prompt — no por tipo e inquilino. Una segunda empresa que editara su propia copia habría sobrescrito silenciosamente la de la primera, mediante SQL totalmente válido, sin error, sin aviso y sin ningún test fallido. Se encontró leyendo todos los índices únicos restantes tras cambiar una clave, uno a uno, con la sospecha de que los ruidosos tenían compañía.
Lo mencionamos porque es la forma honesta de este trabajo. La separación no es una función que se activa; es un hábito de leer las partes aburridas del esquema asumiendo que algo ahí dentro no está de acuerdo contigo.
Los tests, para que conste: 942, ejecutados contra una base de datos reconstruida desde cero en cada cambio. No están ahí para demostrar que el diseño es ingenioso. Están ahí porque el modo de fallo de este diseño concreto es silencioso, y los fallos silenciosos necesitan a alguien que grite en su nombre.
Lo que la separación aporta a una persona normal
- Un grupo puede gestionar varias empresas desde una sola instalación, y un vendedor de una nunca verá un cliente de otra — no por política, sino por construcción.
- Un programa de partners, un conjunto de prompts, una reclamación sobre un cliente: todo con ámbito por empresa, de modo que la configuración de un inquilino no puede convertirse en la de todos.
- Una solicitud de borrado se atiende dentro de un límite en lugar de en un montón compartido, y eso es lo que hace posible responder con honestidad.
- Y nadie tiene que recordarlo. Ese es el punto — una garantía que depende de que alguien la recuerde no es una garantía.
Una línea más que no va de bases de datos
Cada servicio hermano de la familia guarda su propia credencial con nombre. Nada habla con una credencial compartida, así que ningún servicio puede actuar accidentalmente como otro — una pequeña disciplina que surgió directamente de haber tenido alguna vez un token compartido y no disfrutarlo.
Es el mismo instinto que la regla de la base de datos. Haz lo incorrecto imposible en lugar de desaconsejado, y dedicarás tu atención a los clientes en lugar de a la vigilancia.
- 126 tablasCada una lleva su inquilino, con la comprobación forzada.
- 272 políticasEscritas una a una, de modo que cada una ha sido leída por una persona.
- 3942 pruebasContra una base de datos reconstruida desde cero, en cada cambio.
- 40 inquilinos por defectoUna petición sin ámbito nunca llega a los datos.
Medido en la compilación en vivo
«Nuestra aplicación siempre filtra por empresa.»
«Siempre» está haciendo mucho trabajo en esa frase.
Baja el límite hasta la base de datos y una cláusula WHERE olvidada no devuelve nada en lugar de los clientes de otra persona. Una pantalla vacía es un fallo mejor que una presentación incómoda.
Para grupos con varias marcas →