Stateless vs. stateful: cuándo la simplicidad le gana al control
Dos formas legítimas de resolver el mismo problema de mensajería, y cómo elegir entre ellas sin caer en el dogma de 'siempre simple' o 'siempre robusto'.
Hay una pregunta que casi nunca se hace explícita al diseñar un pipeline de mensajería, y que sin embargo determina buena parte de la complejidad futura del sistema: ¿quién recuerda el estado, y por cuánto tiempo?
Dos soluciones al mismo problema
Imaginemos un problema concreto: un evento ocurre en un dispositivo (un mensaje, una lectura de sensor, una notificación) y necesita llegar a otro sistema para ser procesado. Hay dos formas legítimas de resolverlo.
La versión stateful trata cada evento como parte de una relación continua. Autentica el origen con credenciales propias, persiste el evento antes de intentar entregarlo, reintenta si falla, y expone esa historia para auditoría. Es la respuesta correcta cuando el costo de perder un evento es alto, cuando hay múltiples orígenes que deben distinguirse entre sí, o cuando alguien (un cliente, un regulador, un equipo de soporte) eventualmente va a preguntar "¿qué pasó con este evento específico?".
La versión stateless trata cada evento como una unidad autocontenida y desechable. No hay base de datos, no hay reintentos sofisticados, no hay historial. El evento se filtra, se transforma, se envía, y el sistema olvida que existió. Es la respuesta correcta cuando el volumen es bajo, cuando la pérdida ocasional de un evento es tolerable, y cuando el costo de operar y mantener infraestructura con estado supera el valor de la garantía que ofrece.
El error de diseño más común
El error no es elegir la opción equivocada, sino no elegir conscientemente. Es habitual ver sistemas stateful construidos por inercia ("así se hacen las cosas serias") para casos donde nunca nadie necesitó una auditoría, y sistemas stateless que crecieron orgánicamente hasta manejar dinero o datos regulados sin que nadie se detuviera a preguntar si todavía era la decisión correcta.
La pregunta que vale la pena hacerse antes de escribir la primera línea de infraestructura no es "¿qué tan robusto puede ser esto?", sino:
- Si este evento se pierde, ¿alguien lo nota? ¿Cuándo?
- ¿Existe más de un origen que deba distinguirse, con permisos o formatos distintos?
- ¿Alguien, en algún momento, va a necesitar reconstruir qué pasó?
Si las tres respuestas son "no", construir la versión stateful es sobre-ingeniería: estás pagando el costo de mantener credenciales, cifrado y persistencia por una garantía que nadie va a usar. Si alguna respuesta es "sí", la versión stateless no es simplicidad, sino una deuda técnica que todavía no ha cobrado su factura.
Un matiz importante
Estas dos versiones no son necesariamente etapas de madurez de un mismo sistema. Con frecuencia son la misma solución construida dos veces, para dos contextos distintos, y ambas están bien. El objetivo no es que todo termine siendo stateful "porque es lo profesional", sino reconocer explícitamente, para cada integración, qué garantía necesita y diseñar exactamente para esa necesidad, ni más ni menos.
La habilidad de ingeniería aquí no es saber implementar reintentos con backoff exponencial o modelar una tabla de eventos con TTL. Esas son técnicas conocidas. La habilidad real es resistir la presión de construir la versión más sofisticada por defecto, y tener el criterio para decir "esto no necesita persistencia" cuando es cierto, algo que suele ser, casi siempre, la decisión menos intuitiva de tomar.