Arquitectura multiinquilino, sin tecnicismos: una guía para fundadores

En algún momento al crear un producto de software, un desarrollador le dirá la palabra "multiinquilino", observará su cara y dará por hecho que lo ha entendido. Probablemente usted asintió. La mayoría de los fundadores lo hacen. Pero esta es una de esas decisiones tempranas que, en silencio, fija el techo de lo rápido que puede crecer, lo barato que puede operar y lo mal que pueden salir las cosas si un cliente llega a ver datos que no son suyos. Merece diez minutos de su atención ahora, porque revisarla después resulta muy caro.

Me he sentado frente a muchos fundadores sin perfil técnico — personas con una idea afilada para un producto SaaS y sin especial interés en las bases de datos. La buena noticia es que no necesita aprender a programar para tomar bien esta decisión. Necesita un modelo mental claro y una breve lista de preguntas. Eso es esta guía. Sin palabras de moda, sin diagramas de arquitectura que no volverá a mirar, solo lo que su desarrollador desearía que usted entendiera antes de la primera línea de código.

Si se queda con una sola idea, que sea esta: la multitenencia no es una función que se añade después. Es un cimiento. Una casa se puede repintar, pero no es fácil cambiar aquello sobre lo que se asienta una vez que las paredes están levantadas.

Qué significa realmente "multiinquilino"

Imagine un edificio de apartamentos. Cada inquilino tiene su propio piso — su propia llave, sus propios muebles, su propia puerta. Pero todos comparten la misma estructura: los cimientos, las tuberías, el tejado, el ascensor. El propietario mantiene un edificio, no cincuenta casas separadas, y eso es lo que hace que el alquiler sea asequible. El software multiinquilino funciona exactamente así. Una sola aplicación atiende a muchos clientes — "inquilinos" — y cada uno la vive como su propio espacio privado, aunque todos funcionen sobre el mismo sistema compartido por debajo.

El enfoque opuesto es el monoinquilino: cada cliente recibe su propia copia separada del software, como construir una casa unifamiliar nueva para cada uno. Más privado, más personalizable — y muchísimo más caro de construir, operar y actualizar, porque ahora mantiene cincuenta casas en lugar de un edificio.

Casi todos los productos que usa a diario son multiinquilino. Su correo, su herramienta de contabilidad, su sistema de reservas, el CRM en el que vive su equipo de ventas. Usted y otras mil empresas comparten el mismo software subyacente, y ninguno se ve nunca. Esa invisibilidad — esa separación limpia — es todo el arte de la multitenencia.

Por qué esta decisión afecta a todo su negocio

Resulta tentador archivar esto como "detalle técnico del que se ocupa mi desarrollador". Pero el modelo que elija repercute directamente en las partes del negocio que sí le importan: su factura mensual de alojamiento, la rapidez con que puede entregar una nueva función a todos, lo que puede prometer a un comprador empresarial nervioso y cuánto daño puede causar un solo error.

Cuando corrige un error o publica una función en un producto multiinquilino bien construido, todos los clientes la reciben a la vez, con una sola actualización. En un mundo monoinquilino, tendría que desplegar ese cambio en cincuenta instalaciones separadas, cada una quizá un poco distinta a estas alturas. Una cosa es un martes por la tarde. La otra es un proyecto. Multiplíquelo a lo largo de años de actualizaciones y verá por qué la industria SaaS funciona sobre la multitenencia.

La otra cara es que compartir infraestructura eleva lo que está en juego con la separación. En un edificio, una avería de fontanería puede afectar a más de un piso. En el software multiinquilino, un fallo en cómo mantiene separados a los inquilinos no solo incomoda a un cliente — puede exponer los datos de todos a la vez. Esto no es razón para evitar la multitenencia. Es la razón para construirla bien, con alguien que ya lo haya hecho antes.

Las tres formas de mantener separados a los inquilinos

Cuando los desarrolladores discuten sobre multitenencia, suelen discutir sobre cuán separados deben estar los datos de cada inquilino. Hay tres enfoques habituales, y se sitúan en una escala deslizante que va de "máxima compartición, menor coste" a "máxima separación, mayor coste". No tiene que elegir uno usted mismo — pero sí debería entender el compromiso que su desarrollador asume en su nombre.

1. Base de datos compartida, tablas compartidas

Los datos de todos viven en la misma base de datos, en las mismas tablas, con una etiqueta oculta — un "identificador de inquilino" — que marca qué filas pertenecen a quién. El software es responsable de filtrar siempre por esa etiqueta, de modo que el cliente A solo vea las filas del cliente A. Es el modelo más barato y más escalable, el que usan la mayoría de los productos SaaS tempranos. La trampa: la separación vive en el código, así que un único filtro olvidado es la vía por la que se fugan los datos. Exige una ingeniería cuidadosa y disciplinada.

2. Base de datos compartida, compartimentos separados

Una base de datos, pero cada inquilino recibe dentro de ella su propia sección amurallada (los desarrolladores las llaman "esquemas"). Separación más fuerte que en el primer modelo, todavía razonablemente eficiente, y más fácil para, por ejemplo, exportar o borrar limpiamente los datos de un cliente. El compromiso es más piezas móviles que gestionar a medida que crece hacia los cientos y miles de inquilinos.

3. Una base de datos separada por inquilino

Cada cliente recibe su propia base de datos dedicada — lo más parecido a darle una casa privada sin dejar de compartir la aplicación. Es el aislamiento más fuerte y la historia más fácil de contar a un comprador empresarial preocupado por la seguridad. También es el más caro de operar y mantener, por lo que tiende a reservarse a clientes de alto valor, sectores regulados o productos donde una confusión de datos sería catastrófica.

La parte que no puede equivocar: el aislamiento

Si hay un sitio donde gastar su preocupación, es aquí. El aislamiento de inquilinos es la garantía de que el cliente A no pueda jamás, bajo ninguna circunstancia, ver, editar ni siquiera intuir la existencia de los datos del cliente B. Suena obvio. Es también la fuente más común de errores graves en los productos multiinquilino, porque el fallo es silencioso — todo parece ir bien hasta el día en que alguien abre un informe y ve dentro a los clientes de un desconocido.

La razón de que ocurra es estructural. En el modelo más barato, cada solicitud a la base de datos tiene que acordarse de filtrar por inquilino. Hágalo bien diez mil veces y mal una sola, y tiene una fuga. Por eso los equipos con experiencia no confían en que los desarrolladores se acuerden — integran el aislamiento en el cimiento, de modo que olvidarlo se vuelve imposible en lugar de simplemente improbable. No necesita entender cómo lo hacen. Necesita preguntar si lo hacen.

Hay también un pariente más silencioso de este problema: el "vecino ruidoso". Como los inquilinos comparten infraestructura, un cliente que haga algo pesado — una importación gigante, un informe descontrolado — puede ralentizar el sistema para todos los demás, igual que un piso con todos los grifos abiertos puede bajar la presión del agua en todo el edificio. Un buen diseño multiinquilino lo prevé con límites y reparto justo. Merece la pena preguntarlo, sobre todo si espera unos pocos clientes muy grandes.

Cuándo el monoinquilino es realmente la decisión correcta

La multitenencia es lo predeterminado en SaaS, pero no es una religión. Hay razones honestas para dar a un cliente su propia copia separada, y un buen asesor le dirá cuándo ha topado con una de ellas, en vez de forzarlo todo al modelo compartido.

• Un cliente de un sector regulado — sanidad, finanzas, administración pública — cuyas normas de cumplimiento exigen de hecho que sus datos residan en un lugar separado de forma demostrable.
• Un único gran cliente que paga lo suficiente como para que un montaje dedicado merezca la pena, y que desea una personalización profunda que no quiere que se filtre a la experiencia de los demás.
• Datos tan sensibles que el coste de una fuga entre inquilinos acabaría con el negocio, lo que hace que el máximo aislamiento valga el gasto adicional.
• Un requisito de instalación local (on-premise), donde el software debe ejecutarse dentro de los propios muros del cliente y no en su nube.

Fíjese en el patrón: el monoinquilino es la excepción a la que recurre de forma deliberada, normalmente para un cliente concreto de alto valor, no lo predeterminado sobre lo que construye todo el negocio. Si un desarrollador propone monoinquilino para su producto estándar desde el primer día, pídale que le explique por qué — suele significar un coste de operación mucho más alto y actualizaciones más lentas, y querrá que eso sea una elección, no un accidente.

Las preguntas que hacer antes de que nadie escriba código

No necesita diseñar la arquitectura. Necesita asegurarse de que quien lo haga ha pensado en las cosas correctas. Esta es la breve lista que querría que un fundador sin perfil técnico llevara a esa primera conversación — imprímala, hágala, observe con cuánta soltura le responden.

1. 1
   ¿Cómo mantendrán separados los datos de los inquilinos?

   Está atento a una respuesta estructural — el sistema lo impone — no a "seremos cuidadosos". Esta es la innegociable.
2. 2
   ¿Qué modelo usamos, y por qué?

   Tablas compartidas, compartimentos separados o base de datos por inquilino. No hay respuesta equivocada, pero debería haber una razón que encaje con sus clientes y su presupuesto.
3. 3
   ¿Podremos ofrecer aislamiento dedicado a un gran cliente más adelante?

   Aunque empiece totalmente compartido, el diseño debería dejar margen para dar a un cliente grande o regulado una separación más fuerte sin una reconstrucción.
4. 4
   ¿Qué ocurre cuando un cliente se vuelve enorme?

   ¿Cómo evita el sistema que un inquilino pesado ralentice a todos los demás? Querrá oír que se contemplaron escenarios de vecino ruidoso.
5. 5
   ¿Cómo exportamos o borramos limpiamente los datos de un cliente?

   Los clientes se van, y la ley de privacidad exige que elimine sus datos cuando lo soliciten. Esto debería ser una operación sencilla y bien entendida, no un pánico.

No está calificando el detalle técnico de las respuestas. Está comprobando que ninguna de estas preguntas caiga como una sorpresa. Un equipo que ya ha construido software multiinquilino tendrá respuestas nítidas, casi aburridas, a las cinco. La vacilación en la primera o la tercera es la señal para frenar y profundizar.

Un ejemplo breve, con forma de caso real

Un fundador vino a nosotros con un prototipo funcional de una herramienta de citas pensada para pequeñas clínicas. Ya tenía tres clientes de pago — y un problema silencioso. Para salir rápido al mercado, el primer desarrollador había dado a cada clínica su propia copia separada de la aplicación. Tres clientes, tres instalaciones, tres versiones ligeramente distintas, porque cada una había pedido un pequeño ajuste por el camino.

Funcionaba de maravilla con tres. La pesadilla del fundador era pensar en treinta. Cada corrección de error suponía iniciar sesión en tres sitios. Cada nueva función suponía tres despliegues y tres cosas que probar. Poner en marcha una clínica nueva llevaba casi una semana a mano. El modelo que los había llevado al lanzamiento era ahora lo que limitaba su crecimiento — exactamente el problema de cimientos del que trata todo este artículo.

No lo arrancamos todo en una reescritura dramática. Reconstruimos el núcleo sobre un cimiento multiinquilino compartido, con el aislamiento impuesto a nivel del sistema, mantuvimos las personalizaciones por clínica como ajustes configurables en lugar de bases de código separadas, y migramos las tres clínicas existentes una a una, en paralelo, para que nadie tuviera un día de cambio aterrador. Dar de alta una clínica nueva pasó de una semana de trabajo manual a un registro autoservicio. Las nuevas funciones ahora llegan a todos los clientes desde una sola publicación.

Las cifras aquí son ilustrativas, no una promesa — cada producto es distinto —, pero la forma es típica: la reconstrucción costó dinero real y un par de meses, y se amortizó con el primer puñado de clientes nuevos que de pronto pudieron incorporar sin mover un dedo. La lección que el fundador se llevó fue la más barata: si hubieran hecho las cinco preguntas al principio, no habría habido nada que reconstruir.

Preguntas frecuentes