Este artículo técnico parte de una experiencia real con un broker MQTT en clúster para extraer una lección aplicable a cualquier sistema distribuido. Los autores explican cómo dos pods cayeron por OOM con un límite de 512 MiB pese a tener cargas de conexión muy desiguales (8, 174 y 1.039 clientes), y por qué la métrica de uso de memoria, casi idéntica entre nodos, delataba que el problema no era el balanceo sino el modelo.
La causa resultó ser un hook de persistencia que, en el arranque de cada pod, cargaba en memoria el estado de sesión de toda la flota de clientes, no solo de los que pudieran reconectarse a ese nodo. Esa decisión, aparentemente razonable en un clúster sin balanceo sticky, replicaba estado en todos los nodos por si acaso. Los autores lo enmarcan como un caso particular de un error más general que denominan "Consistencia Uniforme": aplicar por defecto la misma garantía de consistencia a todo el estado del sistema, sin preguntarse qué necesita cada pieza.
Frente a ello, proponen la "Consistencia orientada al estado": identificar cada pieza de estado, preguntarse qué pasa si dos nodos discrepan brevemente, determinar la garantía mínima suficiente y elegir el mecanismo más débil que la proporcione. Ilustran el método con una tabla de cinco tipos de estado (propiedad de conexión activa, propiedad de cliente offline, enrutamiento de mensajes, estado durable de mensajes y pertenencia al clúster) y cinco garantías distintas: propietario único autoritativo, determinismo sin arbitraje, disponibilidad tolerante a staleness breve, durabilidad sin excepciones y consistencia eventual. Concluyen que la coherencia no es una propiedad del sistema, sino de cada pieza de estado individual.