当 Commerce 后端运行多个 Pods/ 节点时，当间断的申请过快达到时，后端将无奈在集群中发送缓存生效告诉。此外，如果多个申请扩散到多个节点上，会产生提早和不必要的资源耗费。
Spartacus 尽可能与单个后端进行交互，以服务于单个客户端。这通常被称为 sticky session.
Sticky session（粘滞会话）是一种负载平衡策略，用于在多个服务器之间调配客户端申请。在具备多个 Java 应用服务器的集群中，负载均衡器将客户端申请散发到不同的服务器上，以实现性能优化和高可用性。然而，这可能会导致一个问题：当一个客户端须要与特定服务器上的会话（例如，一个购物车或登录会话）进行交互时，因为负载均衡器将申请分发给不同的服务器，会话数据可能不会保持一致。
为了解决这个问题，引入了粘滞会话（sticky session）策略。粘滞会话策略确保同一个客户端的所有申请都会被调配到之前解决其申请的同一个服务器。这通常是通过将客户端的会话标识符（例如，JSESSIONID）与特定服务器关联来实现的。负载均衡器在将申请散发到服务器之前，会查看申请中的会话标识符，并将申请路由到与该标识符关联的服务器。
粘滞会话确保了会话数据的一致性，但可能导致服务器负载不平衡。如果一个服务器上的用户会话特地沉闷，那么这个服务器的负载可能会变得很高，而其余服务器则绝对较低。因而，在抉择粘滞会话策略时，须要衡量会话数据一致性和负载平衡的需要。
CCv2 在肯定水平上为此做了筹备。它在响应中增加了一个 ROUTE cookie. 然而，该 cookie 无奈进行配置，并且没有 SameSite 策略。这意味着解耦的前端商店很可能无奈应用它，因为它是在不同的域上操作。
为了启用 ROUTE cookie，必须执行以下操作：
- 在 http 客户端中应用 withCredentials: true 选项，以便在每个申请中发送 cookie。
- 应用额定的 CORS 过滤器（Allow-Origin-With-Credentials:true）配置 Commerce backend，以确保 cookie 通过过滤器。