Hi,
This looks like a decent session management strategy for large deployments (where you need to be able to manage a lot more than just a few thousand of active process instances).
It is indeed possible to migrate sessions and process instances to a different DB. Note that a lot more is actually be possible, that your strategy is not using (which might not mean that there is an issue with this of course, just mentioning as this could give you more options to scale as well).
You can move a session from one node to other. So if node1 instantiated a session, but at some point later, node1 is busy, you can restore the same session on node2 and continue execution of the process instance there. So this gives you more flexibility than defined in "For requests pertaining to a specific process instance, consult the table in (5) & (6) and route to appropriate node". But this is probably a trade of between cpu and db (as moving to another node probably means that the session needs to be restored from db while it might be in cache on the original node). We do however recommend to not run the same session in parallel on multiple nodes (as that would usually lead to conflicts and decreased performance. So binding a session to a node isn't necessarily a bad strategy (just means you have some flexibility to reallocate if necessary).
You can even move a process instance to another session. Node that you should only consider this if your process instance is not linked to its session state (otherwise you should always use them together). Examples where session state is used is for example when you are using timers or when you are using business rules anywhere in your process.
We're working on setting up improved session management for cases like this (instantiate session remotely on nodes based on a specific strategy and distribute requests). If you believe this would be something we could collaborate on, let me know !
Kris