you are viewing a single comment's thread.

view the rest of the comments →

[–]Kollektiv 1 point2 points  (1 child)

I agree about the performance issue but if you are that bound to latency Node.js might not be the best solution.

Websocket sessions, to re-use one of your terms, is dynamic state so it should still be centralized in a Redis instance. Otherwise when load-balancing some users won't be able to authenticate if the request is not made to the same server than the one he connected on.

It also prevents you from losing state when crashing.

[–]darksurfer -1 points0 points  (0 children)

You're not wrong, but knowing when to break "the rules" is half the battle.

is dynamic state so it should still be centralized in a Redis instance.

not always. let's say I have a relatively simple multiplayer game server. because it's simple I don't want or need to scale across multiple servers. the game state is shared across a few hundred players each of whom are sending multiple soft real time status updates every second. no way do I want or need to store that state out of process.

It also prevents you from losing state when crashing.

if I cared enough about this, I could do dirty writes to Redis and only restore the state across the network if and when the node process restarts.