Why is it good practice to store session IDs in a database?

Posted by Nathan on 2017-10-18
  1. Audit and analysis. You want a persistent copy of who you handed what session to so as to know who does what in your system. You might say that the userId might be used for this sort of logging but please bear in mind that not all sessions are “logged in”. We have sensitive systems where a client first obtains a session and optionally logs in later. Another case is if you’re supporting “guest” or “anonymous” users on your platform or when you’re supporting multi-login like Google Apps.
  2. Session recovery. If you do a server restart and you’re not running a cluster with session replication built-in, some of your users will get abruptly logged out in the middle of a task. If you’re running on a single compute node with only in-memory session management, all of your users will get logged out. Possibly in the middle of completing an order. You miss sales. Very bad.
  3. Node initialization. This is strategy dependent really, error-prone and might even limit how far you can scale. But the idea is that on server startup, the server fetches active sessions from the source of truth and uses that to setup it’s own local in-memory copy for fast lookups. The main issue here is cache invalidation. As Martin Fowler said, there are two hard things: cache invalidation and naming things.