La única razón para almacenar datos de sesión en una base de datos (MongoDB, Redis, etc.) es tal que está disponible en todos los procesos de Nodo y es duradero en caso de fallas. En las arquitecturas de escala, es altamente deseable tener servidores sin estado para que todo funcione sin importar a qué servidor se conecta un usuario en particular y los servidores pueden subir y bajar sin perder ningún estado.
En otras palabras, imagine que tiene 10 servidores detrás de un manejo de las peticiones entrantes equilibrador de carga. El usuario 1 realiza una solicitud para que el servidor A maneje e inicie sesión. Debe almacenar el hecho de que haya iniciado sesión para poder almacenar esto en una sesión. La siguiente solicitud termina siendo enrutada al Servidor C ya que el Servidor A está ocupado con otra solicitud. Para que el Servidor C sepa que el usuario ya ha iniciado sesión, necesita los datos de la sesión. Entonces, ¿cómo obtiene acceso a los datos de la sesión que almacenó el Servidor A?
Una forma es mediante el almacenamiento de los datos en una cookie en el lado del cliente que se envía con cada solicitud, pero esto no es muy seguro. Otra forma es intentar sincronizar el estado en los servidores de nodo, lo que se puede hacer, pero tiende a ser costoso y propenso a errores. La forma más fácil es almacenar una ID de sesión en una cookie y luego almacenar los datos de la sesión real en una base de datos. Cada servidor de nodo tiene acceso a la misma base de datos para que puedan buscar los datos de la sesión. De esta forma, puede escalar fácilmente dentro y fuera de sus servidores de nodo y equilibrar la carga cuando los servidores fallan sin perder ningún dato.
En términos de rendimiento, la memoria en la tienda va a ser el más rápido (pero no tiene los inconvenientes anteriormente). Redis será el próximo más rápido y MongoDB será el más lento (generalmente 4 veces más lento que Redis). Tenga en cuenta que cualquiera de los dos será lo suficientemente rápido para la gran mayoría de los sitios web.