La gestión de estado a nivel de protocolo en sistemas distribuidos introduce fricción significativa para la escalabilidad horizontal, la resiliencia y la eficiencia operativa. El rediseño del protocolo MCP (Microservice Communication Protocol) hacia un core stateless aborda este problema fundamental, eliminando la necesidad de afinidad de sesión y almacenamiento de estado externo. Este cambio permite que cualquier instancia de servicio procese cualquier solicitud, un principio clave para la elasticidad y la resiliencia en arquitecturas de hyperscaler.
Históricamente, muchos protocolos de comunicación comenzaron con un modelo stateful para simplificar la lógica del cliente y del servidor, asumiendo una conexión persistente o una afinidad de sesión. Sin embargo, a medida que los sistemas crecen en escala y complejidad, la gestión de estado distribuido se convierte en una fuente principal de latencia, fallos y sobrecarga operativa. La evolución de MCP refleja una tendencia más amplia en el diseño de protocolos y APIs, donde la responsabilidad del estado se desplaza hacia el cliente o se gestiona explícitamente a través de tokens opacos, siguiendo principios RESTful y patrones de diseño de sistemas distribuidos modernos.
Arquitectura del Sistema
El nuevo protocolo MCP 2026-07-28 elimina el handshake de inicialización y el header Mcp-Session-Id. Cada solicitud ahora es autocontenida, llevando su propia versión de protocolo y contexto de cliente. Esto permite que cualquier instancia de servidor responda a cualquier solicitud, facilitando el balanceo de carga round-robin sin necesidad de sticky sessions en el Application Load Balancer (ALB). La gestión de estado para casos de uso stateful se delega al cliente, que ahora recibe un identificador de estado (key) del servidor y lo incluye en solicitudes subsiguientes, similar a cómo los clientes REST manejan los recursos.
Para la interacción multi-paso, el patrón Multi Round-Trip Requests (MRTR) reemplaza las conexiones abiertas. Si un servidor necesita más información, devuelve un resultado input_required con un mapa inputRequests y un token requestState opaco. El cliente cumple las solicitudes, reenvía la llamada original con inputResponses y el requestState ecoado. Este token requestState encapsula todo el contexto necesario para que cualquier instancia de servidor reanude la operación, eliminando la necesidad de un shared session store. La observabilidad se integra a nivel de protocolo mediante el uso de W3C Trace Context en el campo _meta para distributed tracing y la adopción de stderr o OpenTelemetry para logging, deprecando los canales de logging propietarios de MCP. La validación de esquemas de entrada/salida de herramientas se realiza mediante JSON Schema 2020-12, fortaleciendo la seguridad y la robustez de la interfaz.
Flujo de Solicitud MCP Stateless
- 1 Cliente Envía solicitud autocontenida (protocol version, client context, tool call)
- 2 ALB Balancea carga a cualquier instancia de servidor (round-robin, sin sticky ses...
- 3 Servidor MCP Procesa solicitud, genera respuesta
- 4 Servidor MCP Si necesita input, devuelve 'input_required' con 'requestState' y 'inputReque...
- 5 Cliente Recibe 'input_required', cumple 'inputRequests'
- 6 Cliente Reenvía solicitud original con 'inputResponses' y 'requestState' ecoado
- 7 ALB Balancea carga a cualquier instancia de servidor (puede ser diferente)
- 8 Servidor MCP Reanuda operación usando 'requestState', completa procesamiento y devuelve re...
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | Elastic Load Balancing Application Load Balancer (ALB) | Balanceo de carga de solicitudes entrantes. Con el nuevo protocolo, puede usar round-robin simple, eliminando la necesidad de sticky sessions. Eliminación de configuración de 'stickiness'. |
| compute | AWS Lambda | Plataforma de ejecución serverless. El protocolo stateless es un ajuste natural para el modelo de 'request in, response out' de Lambda, eliminando workarounds previos. |
| storage | Amazon DynamoDB / Amazon ElastiCache | Almacenamiento de estado de sesión. Con el protocolo stateless, ya no son necesarios para la gestión de sesiones a nivel de protocolo. Decommissioning de infraestructura de sesión. |
| observability | W3C Trace Context / OpenTelemetry / Amazon CloudWatch | Proporcionar tracing distribuido end-to-end y logging estandarizado para depuración y monitoreo. vs Protocol logging propietario de MCP Inclusión de `traceparent`, `tracestate`, `baggage` en `_meta`. |
Trade-offs
Ganancias
- ▲ Escalabilidad horizontal
- ▲ Resiliencia (tolerancia a fallos de instancia)
- ▲ Eficiencia de costos (eliminación de infraestructura de sesión)
- ▲ Simplicidad arquitectónica
- ▲ Observabilidad integrada
- ▲ Seguridad (validación de esquemas, enforcement de propiedad)
Costes
- △ Complejidad del cliente para gestionar el estado de interacción multi-paso
- △ Eliminación de 'server-initiated pushes' (requiere MRTR)
Fundamentos Teóricos
La transición de un protocolo stateful a uno stateless en MCP resuena con los principios fundamentales de la computación distribuida y la arquitectura de sistemas. El concepto de 'statelessness' es un pilar del estilo arquitectónico REST (Representational State Transfer), formalizado por Roy Fielding en su tesis doctoral de 2000. Fielding argumentó que los sistemas stateless mejoran la escalabilidad, la visibilidad y la fiabilidad al eliminar la dependencia del estado del servidor entre solicitudes.
La eliminación de la afinidad de sesión y la adopción de tokens de continuación (como requestState) para interacciones multi-paso se alinea con el patrón de 'compensating transactions' o 'sagas' en sistemas distribuidos, donde las operaciones de larga duración se descomponen en pasos más pequeños e idempotentes que pueden ser reintentados o revertidos. Este enfoque es crucial para la resiliencia en entornos donde los fallos de red o de instancia son comunes. Además, la integración de W3C Trace Context refleja la importancia de la 'observability' como un pilar fundamental, un concepto que ha ganado prominencia en la última década, influenciado por trabajos como los de Google sobre Dapper (Sigelman et al., 2010), que demostraron la necesidad de tracing distribuido para depurar y optimizar sistemas a gran escala.