Deploying to multi-node / cluster environments like k8s and impact on sessions, etc.

[205g0]

Describe the problem

From the docs, in particular the part about $app/stores, it is not clear how we can deploy Sveltekit in multi-node environments such as Kubernetes.

With express I would store session data on a database, single instance or replicated and get always the session from there. Hence, I can scale express indefinitely since it stays stateless. Is this also possible with SvelteKit? Meaning Svelte's session store would always get the session data from a db before it answers the request?

A simple chart of such an architecture:

The problem behind: Even if some cluster orchestration software allows to create sticky sessions, so requests hit the same node, it is not always possible to solve this problem on the cluster layer (e.g., when using BGP, autoscaling down, etc.) and it's in general more complicated than just storing the sessions on the db if latter is fast.

Describe the proposed solution

A paragraph in the docs stating if deploying to a multi-node cluster is possible and/or what trade-offs would be encountered (assuming the cluster layer does not offer sticky sessions).

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[rmunn]

Session handling is left up to you, using the provided hooks. In the configuration you're describing, you would write a handle hook runs first, takes the request, and extracts (for example) a session ID from a cookie and attaches that session ID to request.locals. Then the getSession hook would run, talk to the database and fetch the session data given the session ID, and return an object with the session data that the client should see (which will populate the $session store on the client). (Note: You could also do the DB query in the handle hook rather than the getSession hook, depending on whether you want that session data loaded for endpoints or just for pages. The best way to do that will depend on your app and what precisely you store in the session.)

Which means that scaling up would not be a problem, because session data would always be fetched from the DB service no matter which node answered the request.

[205g0]

Ok, glad to hear and to summarize:

• To "sessionize" a page => in handle, do extract the session ID from the cookie and enrich request.locals, in getSession get session data from db and return in order to populate the $session store in the client
• To sessionize an endpoint => do all above in handle and before returning the endpoint's response; reason: the response depends very much on the session data in a typical app, .e.g,, the settings json of an individual user

Did I get it right?