El estado (statefulness) en aplicaciones distribuidas es uno de los desafíos arquitectónicos más complejos en el desarrollo de sistemas a escala. Mientras los servicios sin estado (stateless) son fáciles de escalar horizontalmente, las aplicaciones que necesitan recordar contexto entre peticiones requieren soluciones específicas que se complican significativamente cuando los servicios corren en múltiples instancias.
Stateless vs Stateful: la distinción fundamental
Un servicio stateless trata cada petición como independiente: no guarda información sobre peticiones anteriores y puede ser atendida por cualquier instancia del servicio. Un servicio stateful mantiene contexto entre peticiones: la sesión de un usuario, el estado de un proceso de larga duración, el progreso en un flujo de múltiples pasos.
El principio de diseño general en microservicios es: hacer stateless todo lo que se pueda, y mover el estado necesario a sistemas especializados para gestionarlo (bases de datos, caches distribuidas, brokers de mensajes). La razón es simple: los servicios stateless se escalan, se reinician y se reemplazan sin impacto en el sistema.
Dónde vive el estado en sistemas distribuidos
- Bases de datos relacionales: El almacén de estado de larga duración por excelencia. Transacciones ACID garantizan consistencia.
- Redis: Estado efímero de alta velocidad: sesiones, caché, locks distribuidos, colas de trabajo.
- Brokers de mensajes (Kafka, RabbitMQ): Estado del flujo de procesamiento en pipelines de datos.
- Distributed caches (Hazelcast, Apache Ignite):
- Object Storage (S3): Estado en forma de archivos grandes con durabilidad garantizada.
El problema de las sesiones en WordPress a escala
WordPress guarda las sesiones de usuario en archivos del sistema de archivos por defecto. En una instalación con múltiples servidores detrás de un load balancer, esto rompe la experiencia del usuario: si una petición la sirve el servidor A (donde está el archivo de sesión) y la siguiente la sirve el servidor B, el usuario pierde su sesión.
La solución es mover las sesiones a un almacén compartido. Redis es la opción más común: el plugin Redis Object Cache o WP Redis configura WordPress para guardar las sesiones y la caché de objetos en Redis, haciendo que todas las instancias del servidor compartan el mismo estado de sesión.
Locks distribuidos: el desafío de las operaciones únicas
Cuando múltiples instancias de un servicio compiten por ejecutar una operación que debe hacerse exactamente una vez (enviar un email de confirmación, procesar un pago, actualizar un contador), se necesita un mecanismo de lock distribuido. Redis ofrece la primitiva SETNX (SET if Not eXists) que permite implementar locks simples, y librerías como Redlock ofrecen implementaciones más robustas.
En el contexto de WordPress, los cron jobs son un ejemplo clásico: si múltiples servidores ejecutan wp-cron.php simultáneamente, algunas tareas pueden ejecutarse más de una vez. Soluciones como WP Cron Control o Action Scheduler proveen mecanismos de lock para evitar ejecuciones duplicadas.
En Octopus Agencia Digital diseñamos arquitecturas distribuidas para aplicaciones WordPress de alta disponibilidad. Si tu proyecto necesita escalar más allá de un servidor, hablemos sobre la arquitectura.
