La entropía de un modelo SaaS dicta que, si la base de datos no está diseñada para la escalabilidad desde el día cero, la gestión de planes terminará colapsando. Desarrollar un sistema multi-tenant no es solo segmentar identificadores de clientes.
Consiste en controlar de forma milimétrica a qué recursos acceden, cuánto pueden consumir y qué ocurre cuando deciden pagar más. Si gestionas un software a medida en Madrid, la arquitectura de pagos es tu núcleo crítico.
Control de acceso basado en características (Feature Flags y Toggles)
En una infraestructura SaaS, no despliegas código diferente para cada cliente. Despliegas una única base de código donde las funcionalidades se activan o restringen de forma dinámica.
Esto se logra aislando la lógica mediante Feature Flags. Si no entiendes la arquitectura base del backend, terminarás llenando tu código de sentencias IF espagueti.
Lo óptimo es inyectar un middleware que valide un arreglo binario o JSON asociado al tenant_id antes de resolver el endpoint. Si el toggle del módulo avanzado está apagado, el acceso retorna un 403 Forbidden instantáneo.
Integración avanzada con motores de facturación (Stripe Billing)
No reinventes la rueda procesando tarjetas. Stripe Billing maneja la recurrencia, los prorrateos y las facturas fallidas de forma superior. Tu única responsabilidad es sincronizar los estados.
Para integrar Stripe y pasarelas de manera robusta, el patrón obligatorio es basarse en Webhooks. Escuchas el evento invoice.paid y actualizas el estado en tu tabla local.
Si dependes de peticiones sincrónicas desde tu frontend hacia tu backend para validar un pago, estás creando un fallo crítico. Cualquier interrupción en la red dejará bases de datos inconsistentes.
Implementación de límites de consumo (Rate Limiting y Quotas)
Vender un plan "Básico" implica frenar a los usuarios antes de que saturen tus servidores. Aquí entra el Rate Limiting (peticiones por segundo) y las Quotas (operaciones por ciclo de facturación).
Apoyarte únicamente en la base de datos transaccional para contar consumos destruirá tu latencia. Necesitas bases en memoria como Redis.
Cada operación que consume un recurso incrementa un contador atómico en Redis. Al final del periodo de facturación, una tarea cron (o evento de Stripe) reinicia las llaves de consumo de ese tenant.
Lógica de base de datos para transiciones (Upgrades & Downgrades)
Escalar de un plan de 10€ a uno de 100€ es fácil. El verdadero infierno técnico en el desarrollo web en España ocurre durante los downgrades. ¿Qué haces con los datos si el usuario baja a un plan con menos capacidad?
La regla de oro de la arquitectura hexagonal e infraestructura dicta: nunca borres, oculta. Implementa un estado de "solo lectura" o de archivo congelado.
Al cambiar el tier_level en la tabla de suscripciones, los triggers de la base de datos o la lógica del dominio deben restringir la creación de nuevos recursos sin corromper los históricos.
CodeZone Pro Tip: Middleware Node.js/Redis para Rate Limiting y Quotas en SaaS
async function enforceTenantQuota(req, res, next) {
const { tenantId, planTier } = req.tenant; // Inyectado vía JWT
const limits = { 'startup': 500, 'business': 5000, 'enterprise': -1 };
if (limits[planTier] === -1) return next();
// Llave única por tenant y mes
const redisKey = `quota:${tenantId}:${new Date().toISOString().slice(0,7)}`;
const currentUsage = await redisClient.incr(redisKey);
if (currentUsage > limits[planTier]) {
return res.status(429).json({ error: 'Quota mensual excedida. Upgrade requerido.' });
}
next();
}El coste oculto de una facturación rígida
Si los límites de suscripción y los webhooks están acoplados directamente al código duro, tu empresa está acumulando una deuda técnica masiva.
Cualquier cambio comercial (como añadir un nuevo plan o ajustar tarifas) obligará a desplegar código nuevo, aumentando la probabilidad de romper la plataforma entera en producción.
En CodeZone afrontamos este desafío separando completamente el dominio de facturación del núcleo de la aplicación al estructurar el software a medida en España, garantizando que las decisiones comerciales no colapsen la estabilidad técnica del servidor.
