La Fundación: Definir los Requisitos del SaaS
Antes de escribir una sola línea de código, el trabajo más crítico en arquitectura SaaS ocurre en papel. Necesitas definir tu modelo de tenancy, tu carga de usuarios esperada, tus requisitos de aislamiento de datos y tu estrategia de facturación. Estos cuatro pilares determinan cada decisión arquitectónica posterior.
Empieza respondiendo: ¿quiénes son tus tenants? ¿Son usuarios individuales, organizaciones, o ambos? ¿Qué datos pueden compartir y cuáles deben estar estrictamente aislados? Un SaaS de salud tiene requisitos de aislamiento muy diferentes a una herramienta de gestión de proyectos. Equivocarse en esto desde el inicio es extraordinariamente caro de corregir después.
Documenta tus requisitos no funcionales explícitamente: tiempos de respuesta bajo carga, SLAs de disponibilidad, restricciones de residencia de datos y requisitos de cumplimiento (GDPR, SOC 2, HIPAA). Estas restricciones reducirán tus opciones tecnológicas significativamente.
Modelos de Multi-Tenancy
Existen tres patrones principales de multi-tenancy, cada uno con compromisos reales. El modelo Silo (base de datos separada por tenant) proporciona el mayor aislamiento y la postura de cumplimiento más sencilla, pero es costoso de operar a escala y hace imposible el análisis cross-tenant sin una capa de agregación.
El enfoque de base de datos compartida con separación por esquema te da un motor de base de datos con un esquema por tenant. Equilibra razonablemente el aislamiento y el costo para hasta unos cientos de tenants. El desafío son las migraciones de esquema: necesitas un ejecutor de migraciones que pueda manejar N esquemas secuencialmente o en paralelo.
El modelo de base de datos completamente compartida (aislamiento de tenant a nivel de fila mediante una columna tenant_id) es el más rentable, pero requiere una auditoría cuidadosa de consultas para evitar filtraciones de datos. Cada consulta debe incluir el filtro tenant_id, y aquí el patrón repositorio o el scoping a nivel de ORM se vuelve innegociable.
Autenticación y Autorización
Nunca construyas autenticación desde cero. Usa un proveedor de identidad probado: Auth0, Cognito, Supabase Auth o Keycloak auto-alojado. Tu trabajo es integrar, no reinventar. SSO mediante SAML 2.0 u OIDC es frecuentemente un requisito para clientes enterprise y añadirlo después del lanzamiento es doloroso.
La autorización es una preocupación separada de la autenticación. Quién eres vs. qué puedes hacer. Implementa Control de Acceso Basado en Roles (RBAC) como mínimo, con roles acotados al tenant. Un "superadmin" en el Tenant A debe tener cero permisos en el Tenant B. Considera el control de acceso basado en atributos (ABAC) si tu modelo de permisos es complejo.
Usa tokens de acceso JWT de corta duración (15-60 minutos) con rotación de token de actualización. Almacena los refresh tokens en cookies httpOnly, no en localStorage. Implementa revocación de tokens mediante una lista de denegación o usando tokens opacos que requieran búsqueda en el lado del servidor.
Estrategia de Datos
Tu ratio lectura/escritura determina tu arquitectura de datos. La mayoría de los productos SaaS son 80% lecturas, 20% escrituras. Esto significa que las réplicas de lectura, las capas de caché (Redis, Memcached) y las respuestas API en caché de CDN pueden reducir drásticamente la carga de la base de datos y mejorar el rendimiento percibido.
Diseña tu esquema de base de datos con índices como preocupación de primer nivel. Una revisión del plan de consulta debe ser obligatoria antes de que cualquier cambio de esquema llegue a producción. Añade registro de consultas lentas desde el primer día — te lo agradecerás a las 3 AM seis meses después.
Considera el event sourcing para registros de auditoría. Los requisitos regulatorios frecuentemente exigen un registro inmutable de quién hizo qué y cuándo. Un registro de eventos de solo adición (Postgres sin UPDATE/DELETE, o un almacén de eventos dedicado) maneja esto elegantemente y permite consultas temporales.
Facturación y Suscripciones
La facturación es la complejidad más subestimada en SaaS. Usa Stripe o Paddle a menos que tengas una razón de peso para no hacerlo. Los casos extremos en la gestión de suscripciones — prorrateo, upgrades a mitad de ciclo, lógica de reintento de pago fallido, flujos de dunning, cumplimiento fiscal — consumirán meses de ingeniería si se construyen desde cero.
Modela tu precio antes de escribir código de facturación. Los modelos basados en uso, por asientos y con funciones bloqueadas tienen diferentes patrones de implementación. Un modelo basado en uso requiere un sistema de medición que pueda agregar eventos y alimentarlos de forma confiable a la facturación.
Implementa un procesador de webhooks para eventos de Stripe. Cada evento de pago (invoice.paid, customer.subscription.deleted, payment_intent.payment_failed) debe ser idempotente — puedes recibir el mismo evento varias veces. Usa el ID de evento de Stripe como clave de idempotencia almacenada en tu base de datos.
Estrategia de Despliegue
Containeriza desde el primer día con Docker. Esto elimina los problemas de paridad de entornos y hace que el escalado horizontal sea sencillo. Define tu docker-compose para desarrollo local y tus manifiestos de Kubernetes (o definiciones de tareas ECS) para producción desde el principio.
Implementa despliegues blue-green o canary para reducir el riesgo. Con un producto SaaS que atiende a múltiples tenants simultáneamente, un mal despliegue que afecte a todos los usuarios a la vez es inaceptable. Un canary que enruta el 5% del tráfico a una nueva versión detecta la mayoría de los problemas antes del despliegue completo.
Tu pipeline de CI/CD debe ejecutar: pruebas unitarias, pruebas de integración, análisis de seguridad (SAST), comprobaciones de vulnerabilidades de dependencias y un despliegue de staging con pruebas de humo — antes de que cualquier código toque producción. Automatiza todo. Los pasos de despliegue manual son incidentes esperando suceder.