Multi-tenancy en plataformas SaaS financieras

¿Qué es multi-tenancy y por qué importa en Fintech?

Multi-tenancy es cuando una sola instancia de tu aplicación sirve a múltiples clientes (tenants), cada uno con sus propios datos completamente aislados. En una plataforma financiera, esto no es opcional - es crítico.

Imagina una plataforma donde diferentes fondos de inversión gestionan sus portafolios. El Fondo A nunca debe ver los datos del Fondo B, ni siquiera por accidente. Un error aquí no es solo un bug - es una violación de compliance que puede costarte la licencia.

Los tres enfoques principales

1. Base de datos separada por tenant

Cada cliente tiene su propia base de datos. Es el enfoque más seguro pero también el más costoso y difícil de mantener.

Ventajas:

• Aislamiento total
• Fácil de cumplir con regulaciones de datos
• Backups y restauración por cliente

Desventajas:

• Costoso en infraestructura
• Migraciones de esquema son una pesadilla
• Difícil de escalar a muchos tenants

2. Esquema separado por tenant

Una sola base de datos, pero cada cliente tiene su propio esquema (conjunto de tablas).

Ventajas:

• Buen balance entre aislamiento y costo
• Más fácil de mantener que bases separadas

Desventajas:

• Las migraciones siguen siendo complejas
• Límites de esquemas en algunas bases de datos

3. Tablas compartidas con tenant_id

Todos los clientes comparten las mismas tablas, pero cada fila tiene un identificador de tenant.

Ventajas:

• Más económico
• Migraciones simples
• Escala bien a miles de tenants

Desventajas:

• Un bug puede exponer datos de otros clientes
• Requiere disciplina extrema en queries

Row Level Security: tu red de seguridad

En plataformas como FundLayer, usamos el tercer enfoque (tablas compartidas) pero con una capa adicional de seguridad: Row Level Security (RLS).

RLS es una feature de bases de datos como PostgreSQL que aplica filtros automáticamente a nivel de base de datos. No importa qué query ejecutes - la base de datos siempre filtra por el tenant actual.

Cómo funciona en la práctica

1. El usuario se autentica y su sesión incluye el tenant_id
2. La base de datos conoce ese tenant_id del contexto de la sesión
3. Cada tabla tiene una política que dice: "solo muestra filas donde tenant_id = tenant actual"
4. Incluso si un desarrollador olvida el filtro en su query, RLS lo aplica automáticamente

Por qué esto es revolucionario

Sin RLS, dependes de que cada desarrollador, en cada query, en cada endpoint, recuerde filtrar por tenant. Es cuestión de tiempo hasta que alguien lo olvide.

Con RLS, el filtro está en la base de datos. Es imposible saltárselo accidentalmente. Puedes hacer SELECT * FROM transactions y solo verás las de tu tenant.

Decisiones de arquitectura importantes

El contexto del tenant

¿Cómo sabe tu aplicación qué tenant está haciendo la petición? Hay varias formas:

• Subdominio: fondoa.plataforma.com vs fondob.plataforma.com
• Header HTTP: Un header como X-Tenant-ID en cada request
• Token JWT: El tenant_id viene dentro del token de autenticación

En aplicaciones financieras, recomiendo el token JWT. Es más seguro porque el tenant viene firmado criptográficamente - no puede ser manipulado por el cliente.

Datos compartidos vs datos por tenant

No todo debe estar aislado. Algunos datos son globales:

• Catálogo de productos financieros
• Configuraciones de sistema
• Usuarios administradores de la plataforma

Otros son estrictamente por tenant:

• Transacciones
• Clientes del fondo
• Documentos y contratos
• Reportes

Diseñar bien esta separación desde el inicio te ahorra meses de refactoring después.

Auditoría y compliance

En Fintech, cada acción debe quedar registrada. Tu sistema de auditoría también debe ser multi-tenant:

• Quién hizo qué, cuándo, desde dónde
• Cambios en datos sensibles
• Accesos a información de clientes

Esto no es solo buena práctica - es requisito regulatorio en la mayoría de jurisdicciones.

Errores comunes que he visto

1. Confiar solo en el código de aplicación

"Ya filtramos en el backend" no es suficiente. Un solo endpoint mal escrito expone todo. RLS a nivel de base de datos es tu respaldo.

2. No testear el aislamiento

Debes tener tests automáticos que intenten acceder a datos de otros tenants. Si alguna vez pasan, tienes un problema serio.

3. Olvidar los jobs en background

Tu API puede estar perfecta, pero ¿qué pasa con los cronjobs, workers, y procesos en background? También necesitan contexto de tenant.

4. Logs con datos sensibles

Cuidado con qué logeas. Un log que incluye datos de múltiples tenants mezclados es un riesgo de seguridad.

Conclusión

Multi-tenancy en Fintech no es solo una decisión técnica - es una decisión de negocio y compliance. Hacerlo bien desde el inicio te permite escalar a cientos de clientes sin reescribir tu plataforma.

La combinación de tablas compartidas + Row Level Security + buenas prácticas de auditoría es el sweet spot para la mayoría de plataformas SaaS financieras. Es económico, seguro, y te deja dormir tranquilo sabiendo que un bug no va a exponer datos de otros clientes.