Managing Node.js - Express Sessions with Redis

Article Summary: Learn how & why you should use Redis in-memory database storage for scalable Node.js / Express application session management (because the express-session store is not scalable).

It is red. Red it is. Redis it.

Overview

If you have ever created a local Node.js / Express application that uses session variables for data persistence (i.e. req.session), then you have probably used the express-session library that comes along with most boilerplate Express server configurations.

You may have also noticed that the express-session docs explicitly state the following:

Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.

If you have never been exposed to production application architecture, then this information might confuse you a bit. It is assuming that we probably have multiple instances of our application running (and perhaps on multiple boxes) under a load balancer like NGINX that is taking some kind of round-robin approach to fulfilling client requests.

With a setup like this, a typical user journey may comprise of the following: