The MCP standard is evolving and there is a push to make MCP protocol completely stateless. Having said that this is on a roadmap for the end of this year so the questions remain on how to handle stateful sessions behind a load balancer.
-
We ask the customers to ensure that the first stage load balancer supports a sticky session based on a HTTP header. It has to be on the header as there is always a risk that the MCP client terminates the tcp session between the calls. This is the most performant solution from our perspective and probably the simplest but it requires an interaction with a customer and ensuring that they have a proper environment.
-
We add a remote session management where dataplane components use Redis/external cache to synchronize the session ids. This is slower and more error prone as it is not always guaranteed that session id can be found in the Redis database. Additionally, supporting sessions would require additional complexity of mapping downstream session id to potentially many upstream session ids.
-
We don't support active-active deployments at all in the anticipation of incoming protocol change. If the performance is satisfactory then we could rely on active-hot-standby deployment where we don't need to use Redis to synchronize session ids. In case of failure, the new server will pick up the traffic and the clients will need to re-initialize.
The MCP standard is evolving and there is a push to make MCP protocol completely stateless. Having said that this is on a roadmap for the end of this year so the questions remain on how to handle stateful sessions behind a load balancer.
We ask the customers to ensure that the first stage load balancer supports a sticky session based on a HTTP header. It has to be on the header as there is always a risk that the MCP client terminates the tcp session between the calls. This is the most performant solution from our perspective and probably the simplest but it requires an interaction with a customer and ensuring that they have a proper environment.
We add a remote session management where dataplane components use Redis/external cache to synchronize the session ids. This is slower and more error prone as it is not always guaranteed that session id can be found in the Redis database. Additionally, supporting sessions would require additional complexity of mapping downstream session id to potentially many upstream session ids.
We don't support active-active deployments at all in the anticipation of incoming protocol change. If the performance is satisfactory then we could rely on active-hot-standby deployment where we don't need to use Redis to synchronize session ids. In case of failure, the new server will pick up the traffic and the clients will need to re-initialize.