Desacoplando la Autenticación: De SaaS a Control Propio para Resiliencia y Flexibilidad

El problema fundamental que aborda este artículo es la tensión entre la conveniencia de los servicios de autenticación de terceros y la necesidad de control granular, fiabilidad y escalabilidad en sistemas distribuidos complejos, especialmente aquellos con componentes sociales. La delegación completa de la tabla de usuarios y la gestión de sesiones a un proveedor externo introduce puntos únicos de fallo y limitaciones operativas que pueden impactar severamente la disponibilidad y la experiencia del usuario.

Históricamente, la autenticación ha sido un componente crítico y complejo, propenso a vulnerabilidades de seguridad si no se implementa correctamente. Esto ha llevado al surgimiento de soluciones SaaS que prometen abstraer esta complejidad. Sin embargo, para aplicaciones con requisitos específicos de rendimiento, integración de datos o resiliencia, la abstracción excesiva puede convertirse en una camisa de fuerza. La decisión de Val Town de migrar de un SaaS a una solución de código abierto autohospedada refleja una maduración en la comprensión de los trade-offs entre la velocidad de desarrollo inicial y la sostenibilidad operativa a largo plazo en un entorno de producción.

Arquitectura del Sistema

La arquitectura original de Val Town, al usar Clerk, delegaba la gestión de usuarios y sesiones a un servicio externo. Clerk actuaba como la 'tabla de usuarios' y el gestor de sesiones, emitiendo tokens JWT y gestionando la renovación de sesiones a través de un subdominio de Val Town que redirigía las solicitudes a la API de Clerk. Esto significaba que la aplicación de Val Town no tenía una tabla de usuarios local ni responsabilidad directa sobre las sesiones, confiando completamente en la disponibilidad y el rendimiento de la API de Clerk.

Las limitaciones de esta arquitectura incluían una tasa de 5 solicitudes/segundo para la API de carga de datos de usuario, lo que impedía la recuperación de perfiles de usuario para funcionalidades sociales. Esto forzó la implementación de un mecanismo de sincronización de datos mediante webhooks de Clerk a la base de datos de Val Town, introduciendo complejidad y eventual inconsistencia de datos. La gestión de sesiones, al ser completamente externa, convertía a Clerk en un punto único de fallo crítico: cualquier interrupción en Clerk resultaba en una interrupción total del servicio para los usuarios logueados.

La nueva arquitectura con Better Auth cambia este paradigma. Val Town ahora gestiona su propia tabla de usuarios y sus sesiones. Better Auth, como proyecto de código abierto, se integra directamente en la infraestructura de Val Town, permitiendo un control total sobre la lógica de autenticación y la gestión de sesiones. Aunque Better Auth ofrece servicios de infraestructura pagados, estos son 'stateless' y no están involucrados en la gestión crítica de sesiones, lo que elimina el punto único de fallo externo. La transición implicó un período de coexistencia de dos semanas, donde los endpoints de autenticación aceptaban cookies de ambos sistemas, facilitando una migración gradual de usuarios.

Fundamentos Teóricos

Este escenario resuena con principios fundamentales de sistemas distribuidos, particularmente en lo que respecta a la fiabilidad y la disponibilidad. El concepto de 'punto único de fallo' (Single Point of Failure, SPOF) es central aquí. La dependencia de un servicio externo para una función crítica como la autenticación y la gestión de sesiones introduce un SPOF, donde la fiabilidad del sistema compuesto es, como mínimo, la fiabilidad de su componente más débil. Esto se alinea con la Ley de Amdahl, aunque más comúnmente aplicada al rendimiento, su principio subyacente de que el cuello de botella de un sistema limita su capacidad general se extiende a la fiabilidad.

Desde una perspectiva de diseño de bases de datos, la idea de 'considerar eliminar tu tabla de usuarios' choca con el principio de 'fuente única de verdad' (Single Source of Truth). Mantener la información del usuario distribuida o replicada sin un control claro de la autoridad introduce problemas de consistencia de datos, como se experimentó con la sincronización entre Clerk y la base de datos de Val Town. Esto se relaciona con los desafíos de la consistencia eventual en sistemas distribuidos y la complejidad de los algoritmos de replicación de datos, como los CRDTs (Conflict-free Replicated Data Types), aunque en este caso, el problema surge de la falta de control sobre la replicación y la autoridad de los datos.