Stateless y stateful

El estado es todo lo que un programa necesita recordar para hacer su trabajo: quién inició sesión, qué hay en el carrito, las filas de una base de datos. Un componente stateless (sin estado) no guarda nada de eso entre pedidos. Cada pedido llega con todo lo necesario para responderlo, o el componente lo busca en otro lado. Uno stateful (con estado) guarda esa memoria adentro suyo, en su RAM o en su propio disco.

La diferencia pesa mucho en la nube. Los servidores stateless son intercambiables: un balanceador de carga puede mandar cualquier pedido a cualquier copia, el autoscaling puede sumar diez más durante un pico y borrarlas después, y si una se cae no se pierde nada. Por eso el consejo habitual es hacer stateless los servidores web y de API, y llevar el estado a servicios pensados para guardarlo, como una base de datos, una caché o un almacenamiento de objetos. El propio HTTP es un protocolo sin estado; los logins funcionan porque el navegador manda una cookie o un token en cada pedido.

Los sistemas stateful, como las bases de datos, las colas de mensajes o el servidor de un juego multijugador, son más difíciles de operar. No podés matar una copia o levantar otra así nomás; los datos hay que replicarlos, respaldarlos y moverlos con cuidado. En Kubernetes, por ejemplo, las apps stateless usan Deployments y las stateful necesitan StatefulSets y volúmenes persistentes. El objetivo no es evitar el estado, que toda app útil tiene, sino tenerlo en pocos lugares bien cuidados.