Un Stateless Protocol es un paradigma de diseño de comunicación donde el servidor no retiene ninguna información de estado sobre las solicitudes anteriores de un cliente. Cada solicitud se trata de forma independiente y autónoma; el servidor no almacena el contexto de la sesión entre solicitudes. Esto significa que cada solicitud debe contener toda la información necesaria para que el servidor la complete, como credenciales de autenticación, parámetros de la solicitud y cualquier otro dato relevante. La ausencia de estado en el servidor simplifica su diseño y lo hace inherentemente más robusto y escalable, ya que no necesita gestionar ni sincronizar el estado de la sesión.
El ejemplo más prominente de un Stateless Protocol es HTTP/1.x, el protocolo subyacente de la World Wide Web. Cada solicitud HTTP (GET, POST, PUT, DELETE) es independiente y el servidor no recuerda las solicitudes anteriores del mismo cliente. Otros ejemplos incluyen DNS (Domain Name System), donde cada consulta de resolución de nombre es una transacción independiente, y muchos protocolos de API RESTful, que adhieren a los principios de REST, incluyendo la naturaleza sin estado. En estos sistemas, cualquier estado de sesión necesario se gestiona típicamente en el cliente (por ejemplo, mediante cookies o tokens JWT) o se pasa explícitamente en cada solicitud.
Para un arquitecto de sistemas, la elección de un Stateless Protocol es crucial por varias razones estratégicas. Primero, facilita enormemente la escalabilidad horizontal: cualquier servidor puede manejar cualquier solicitud, lo que permite añadir o eliminar instancias de servidor sin afectar la lógica de la sesión. Segundo, mejora la resiliencia y la tolerancia a fallos, ya que la caída de un servidor no implica la pérdida de estado de sesión para los clientes. Tercero, simplifica la implementación de balanceadores de carga, ya que no necesitan mantener la afinidad de sesión (sticky sessions). Sin embargo, el trade-off es que el cliente debe incluir más datos en cada solicitud, lo que puede aumentar el tamaño de los mensajes y, en algunos casos, la latencia. Además, la gestión del estado de la sesión se desplaza al cliente o a una capa de almacenamiento de estado externa (como una base de datos o un caché distribuido), lo que introduce su propia complejidad de diseño y gestión.