Darkredgm

El modelo Software as a Service (SaaS) ha transformado la industria del software. En lugar de vender licencias únicas, las empresas ofrecen acceso a sus aplicaciones mediante suscripciones recurrentes. Pero detrás de cada SaaS exitoso hay un desafío arquitectónico fundamental: ¿cómo servir a miles de clientes (tenants) desde una misma infraestructura sin que interfieran entre sí?

La respuesta es la arquitectura multi-tenant, y su implementación correcta marca la diferencia entre un negocio rentable y uno que se hunde bajo el peso de su propia complejidad.

¿Qué es Multi-Tenancy?

En una arquitectura multi-tenant, una sola instancia de la aplicación sirve a múltiples clientes (tenants), donde cada tenant experimenta la aplicación como si fuera exclusiva para él. Sus datos están completamente aislados de los demás tenants, puede tener su propia configuración y, en algunos casos, su propio dominio personalizado.

La alternativa es el modelo single-tenant, donde cada cliente tiene su propia instancia desplegada. Esto es más simple de implementar pero escala pobremente: 100 clientes significan 100 despliegues, 100 bases de datos, 100 actualizaciones independientes.

Estrategias de Aislamiento de Datos

1. Base de datos compartida, esquema compartido

Todos los tenants comparten las mismas tablas, diferenciados por una columna tenant_id:

// Modelo con scope de tenant automático
class Order extends Model
{
    protected static function booted()
    {
        static::addGlobalScope('tenant', function ($query) {
            $query->where('tenant_id', auth()->user()->tenant_id);
        });
    }
}

Ventajas: Menor coste de infraestructura, despliegue y mantenimiento simples. Desventajas: Riesgo de filtración de datos si el scope falla, rendimiento compartido entre tenants.

2. Base de datos compartida, esquemas separados

Cada tenant tiene su propio esquema dentro de la misma base de datos PostgreSQL. Las tablas están completamente aisladas:

// Cambiar al esquema del tenant activo
DB::statement("SET search_path TO tenant_{$tenantId}");

Ventajas: Aislamiento más fuerte que la opción anterior, migraciones independientes posibles. Desventajas: Complejidad en la gestión de conexiones, limitado por el número máximo de esquemas de la base de datos.

3. Bases de datos separadas por tenant

Cada tenant tiene su propia base de datos completamente independiente. El aislamiento es total:

// Configurar conexión dinámica al tenant
Config::set('database.connections.tenant', [
    'driver' => 'pgsql',
    'database' => "tenant_{$tenantId}",
    // ...
]);
DB::purge('tenant');
DB::reconnect('tenant');

Ventajas: Aislamiento perfecto, backups y restauración por tenant, rendimiento independiente. Desventajas: Mayor coste de infraestructura, despliegue de migraciones más complejo.

Nuestra recomendación: usa la opción 1 (tabla compartida con tenant_id) para startups y productos en fase inicial. Migra a la opción 3 (bases de datos separadas) cuando tengas clientes enterprise que requieran aislamiento contractual. Un buen diseño permite esta migración sin reescribir la lógica de negocio.

Gestión de Usuarios y Roles

Roles dentro del tenant

Cada tenant necesita su propia jerarquía de roles. Un modelo típico incluye:

Owner — Creador del tenant. Puede gestionar la suscripción, invitar usuarios y acceder a toda la configuración.
Admin — Gestiona usuarios y configuración dentro del tenant, pero no puede modificar la suscripción.
Member — Usuario estándar con acceso a las funcionalidades del producto.
Viewer — Solo lectura. Ideal para clientes o stakeholders externos.

En Laravel, implementamos esto con un sistema de permisos basado en spatie/laravel-permission, donde los roles y permisos son scoped al tenant actual.

Invitaciones y onboarding

El flujo de invitación de usuarios es crítico para la adopción. Cuando un owner invita a un nuevo miembro, el sistema debe:

Generar un token de invitación único y temporal.
Enviar un email con el enlace de registro.
Asociar automáticamente al nuevo usuario con el tenant correcto y el rol asignado.
Registrar la invitación en el log de auditoría.

Suscripciones y Facturación

Integración con Stripe

Laravel Cashier simplifica enormemente la integración con Stripe para gestión de suscripciones. Permite manejar:

Planes con precios escalonados — Básico, Profesional, Enterprise con diferentes límites de funcionalidades.
Períodos de prueba — Free trials de 14 o 30 días sin tarjeta de crédito.
Upgrades y downgrades — Cambio de plan con prorrateo automático.
Facturación por uso — Cobrar por número de usuarios, transacciones o almacenamiento consumido.
Webhooks — Reaccionar a eventos de Stripe como pagos fallidos, cancelaciones o disputas.

Feature flags por plan

No todos los tenants deben ver las mismas funcionalidades. Implementamos feature flags vinculados al plan de suscripción:

// Verificar acceso a una funcionalidad
if ($tenant->plan->hasFeature('advanced_reports')) {
    // Mostrar reportes avanzados
} else {
    // Mostrar banner de upgrade
}

Esto permite crear urgencia de upgrade mostrando a los usuarios funcionalidades premium bloqueadas, incrementando la tasa de conversión de free a paid.

Personalización y White-Label

Los clientes enterprise valoran la capacidad de personalizar la aplicación con su marca. Un buen sistema multi-tenant permite:

Dominio personalizado — El tenant accede a app.suempresa.com en lugar de suempresa.tuproducto.com.
Logo y colores — Cada tenant puede subir su logo y definir su paleta de colores.
Emails personalizados — Las notificaciones se envían desde el dominio del tenant, no desde el tuyo.

Monitorización y Rendimiento

Métricas por tenant

Monitorizar el rendimiento por tenant es esencial para detectar anomalías. Un tenant que consume recursos excesivos puede afectar a los demás. Implementamos métricas individuales para:

Número de peticiones por minuto por tenant.
Tiempo medio de respuesta por tenant.
Uso de almacenamiento por tenant.
Queries lentas asociadas a un tenant específico.

Con estos datos, podemos aplicar throttling selectivo a tenants que abusan del sistema o notificarles para que actualicen su plan.

Conclusión: Multi-Tenancy es la Base del SaaS Rentable

Construir una arquitectura multi-tenant correctamente desde el principio ahorra meses de refactorización posterior. La clave es elegir la estrategia de aislamiento adecuada para tu fase actual del negocio, con la flexibilidad de migrar a estrategias más robustas conforme escales.

En Darkredgm, hemos diseñado y construido plataformas SaaS multi-tenant que sirven a cientos de empresas simultáneamente. Si estás considerando lanzar un producto SaaS, podemos ayudarte a diseñar la arquitectura que te permita escalar sin dolor.

Arquitectura Multi-Tenant para SaaS: Diseño, Escalabilidad y Rentabilidad