<p>Stateless is the way to go for services running in pods however i have been trying to move a stateful app which needs to perform session persistence if one pod goes does for resiliency reasons.</p>

<p>In websphere world IHS can be used to keep track of the session and if a node goes down it can be recreated on the live clone. </p>

<p>Is there an industry standard way to handle this issue without having to refactor the applications code by persisting the session using some sidecar pod ?</p>

Sudheej
<p>Yes. Store the session somewhere. Spring boot supports out of the box MongoDB, Redis, Hazelcast or any JDBC database.</p>

<blockquote>
  <p>Spring Boot provides Spring Session auto-configuration for a wide
  range of data stores. When building a Servlet web application, the
  following stores can be auto-configured:</p>
  
  <p>JDBC Redis Hazelcast MongoDB When building a reactive web application,
  the following stores can be auto-configured:</p>
  
  <p>Redis MongoDB If a single Spring Session module is present on the
  classpath, Spring Boot uses that store implementation automatically.
  If you have more than one implementation, you must choose the
  StoreType that you wish to use to store the sessions. For instance, to
  use JDBC as the back-end store, you can configure your application as
  follows:</p>
  
  <p>spring.session.store-type=jdbc </p>
  
  <p>[Tip] You can disable Spring Session by
  setting the store-type to none. Each store has specific additional
  settings. For instance, it is possible to customize the name of the
  table for the JDBC store, as shown in the following example:</p>
  
  <p>spring.session.jdbc.table-name=SESSIONS </p>
  
  <p>For setting the timeout of the
  session you can use the spring.session.timeout property. If that
  property is not set, the auto-configuration falls back to the value of
  server.servlet.session.timeout.</p>
</blockquote>
