Persistent session stores are ideal when you want server side sessions and a
clean separation of concerns (your code doesn’t need to know details as long as
it knows how to talk to the server). Redis expands on these benefits by giving
us:

Redis makes a compelling case for session data, but as with any technology
decision it’s important to be aware of the trade-offs. Adding Redis to your
stack can mean:

time spent installing, configuring, and maintaining a Redis instance

speed before consistency (Redis is fast at the cost of syncing eventually)

the entirety of your session data must fit in memory

Typically these aren’t concerns for sessions, because critical data doesn’t
usually belong in a client session. However, in specialized cases where you need
consistency at the cost of speed, you may consider database-backed
sessions using a proven database server like
PostgreSQL.

Alternatively, if you only ever store less than ~4kb of non-sensitive
data, cookie-based sessions work nicely without requiring you to add complexity
to your stack.