Un sistema, varios clientes, sin volverse un desorden
Cómo un solo sistema atiende a varias empresas sin mezclar los datos de nadie, y qué se rompe cuando llega el primer cliente grande.
El problema que resuelve multi-tenant
Multi-tenant es cuando el mismo sistema atiende a varios clientes, y cada uno ve solo lo suyo. Parece un detalle técnico, pero es decisión de negocio: es lo que separa vender un software de vender el mismo software cincuenta veces.
La alternativa es levantar una copia por cliente. Funciona con los tres primeros y se vuelve un infierno en el décimo, cuando necesitas aplicar una corrección y tienes diez servidores, diez bases y diez versiones ligeramente distintas.
Tres formas de aislar, y el precio de cada una
Una base por cliente es el aislamiento más fuerte y el más caro de mantener: cada migración corre N veces y cualquier reporte que cruce clientes se vuelve trabajo manual.
Un esquema por cliente es el punto medio, y en escala suele ser lo peor de ambos mundos: sigues multiplicando migraciones, pero ya perdiste la simplicidad de la base única.
Una columna de cliente en cada tabla es lo que uso en la mayoría de los casos. La migración corre una vez, el reporte es una consulta, y el aislamiento pasa a depender de la disciplina en el acceso, que es donde está el riesgo.
El error que filtra datos entre clientes
Con columna de cliente, la filtración no ocurre por intrusión. Ocurre por olvido: una consulta sin el filtro del cliente, en un reporte que nadie revisó, y de pronto un cliente ve el número del otro.
Por eso el filtro no puede depender de que el desarrollador se acuerde. Tiene que estar en la capa que lee la base, aplicado por defecto, de manera que consultar sin cliente definido sea un error y no un descuido. Si tu base soporta política por fila, mejor todavía: la regla vive junto al dato.
Una sola dirección
Un subdominio por cliente parece profesional y cobra caro después: certificado, DNS y un montón de casos raros de login entre dominios.
Prefiero una dirección única, con el cliente resuelto después del login. Quien necesita marca propia la recibe en la pantalla, no en la URL. Y cuando alguien realmente necesita su propio dominio, ahí sí vale el trabajo, para ese cliente.
Qué se rompe cuando llega el cliente grande
Mientras todos son pequeños, todo parece rápido. El primer cliente con volumen alto revela lo que estaba escondido: consulta sin índice por el campo del cliente, reporte que recorre la tabla entera, y trabajo pesado corriendo dentro de la petición en vez de en una cola.
Nada de eso es difícil de resolver, pero es mucho más barato resolverlo antes, cuando todavía se puede cambiar el formato de los datos sin avisarle a nadie.
Cómo lo armo hoy
Base única con columna de cliente, filtro aplicado en la capa de acceso, índice compuesto empezando por el cliente, una sola dirección y trabajo pesado en cola. Es lo que corre en Fluxnavi y en lo que construyo para clientes.
Si estás armando un SaaS ahora, esta es la hora barata de acertar. Después de cien clientes, cambiar el aislamiento es una migración, no una decisión.
¿Tienes un sistema al aire sin dueño?
Tomo lo que otra persona empezó, cierro lo que se fuga y sigo desde ahí.