Redis session store

Store web sessions in Redis.

When to use a session store

Use a Redis session store when you need to share per-user session state (login context, shopping carts, preferences) across stateless application servers without sticky sessions or database round-trips.

Why the problem is hard

HTTP is stateless, so you must rely on external state to recognize a returning user between requests. Some of the obvious approaches have significant drawbacks:

  • Storing sessions on individual app servers: this requires sticky routing, which creates hot spots and precludes failover.
  • Moving session reads to a relational database: this adds 5–20 ms per request. If you have thousands of concurrent users then session reads dominate connection pools. This turns every page load into a contention point that degrades the primary database for all other workloads.

Sessions need automatic cleanup without external sweep jobs. You will incur direct business costs (abandoned carts, forced re-authentication, interrupted checkouts) if you lose sessions, so durability matters more than it does with pure caching.

At operational scale, you also need to run queries against multiple sessions (for example, find all carts containing a recalled product, count sessions per tenant), which is more complicated than just reading individual sessions.

What you can expect from a Redis solution

You can:

  • Eliminate sticky sessions so any instance can serve any user behind a load balancer.
  • Expire inactive sessions automatically without cleanup jobs or database sweeps.
  • Update individual session fields without re-serializing the full session.
  • Track sessions across multiple devices per user, including logout-all.
  • Query across active sessions for operational and security tasks without key scanning.
  • Retain session data across deployments and node restarts with configurable durability.

How Redis supports the solution

In practice, each session is stored as a Redis hash — one hash per session ID — and the key is set to expire automatically so inactive sessions are cleaned up without any external job.

Redis provides the following features that make it a good fit for session storage:

  • Hashes for field-level session access without deserializing an entire session blob.
  • EXPIRE with sliding TTL resets on each request so active sessions stay alive while inactive ones are cleaned up automatically.
  • Sets (SADD, SMEMBERS) to track all sessions per user for multi-device management (DEL plus SREM handle explicit logout or logout-all).
  • AOF and RDB persistence to let sessions survive process and node restarts within their expiration window.
  • Secondary indexing (querying by field values rather than by key) via Redis Search to support cross-session queries at runtime (finding affected carts, counting sessions by tenant) without key scanning.
  • Sub-millisecond latency on the request path, which is already on the same Redis instance in most stacks.

Ecosystem

The following libraries and frameworks provide Redis session store integrations:

Code examples to build your own Redis session store

The following guides show how to build a simple Redis-backed session store. Each guide includes a runnable example to illustrate using the session store with a basic local web server for each of the following client libraries:

RATE THIS PAGE
Back to top ↑