Redis as cache layer: KV store, sessions, rate limits, pub/sub

What is Redis?

Redis is an in-memory data-structure store, used primarily as cache, session store, job queue, rate limiter, and pub/sub broker. Developed since 2009 by Salvatore Sanfilippo, since 2020 under Redis Labs / Redis Inc. In May 2026, version 8 is stable, with improved cluster mode, new data structures, and native vector search via RediSearch.

License model: Redis was historically under BSD license. In March 2024, Redis Inc. switched to the Server Side Public License (SSPL) and Redis Source Available License (RSAL) -- similar to MongoDB. In response the Linux Foundation founded the fork Valkey under the original BSD license, which is available as a drop-in replacement in many Linux distros by 2025. In May 2026, Valkey 8.0 is the vehicle of the pure OSS world -- AWS ElastiCache, Google Cloud Memorystore, and Azure Cache for Redis all offer Valkey as an alternative.

Functionally Redis is far more than a key-value store. Data structures include: strings, lists, sets, sorted sets, hashes, streams (for event sourcing), bitmaps, HyperLogLog (probabilistic counters), geospatial indexes, bitfields. Extensible with modules: RedisJSON (JSON storage), RediSearch (full-text and vector), RedisTimeSeries (time series), RedisGraph (graph DB, EOL since 2024).

In the Swiss SME stack, Redis is the indispensable sidekick to PostgreSQL: Express/Fastify sessions, rate limiting (100 requests per minute per IP), job queue with BullMQ, pub/sub for real-time notifications, cache layer in front of expensive DB queries or LLM API calls. Whoever builds a SaaS almost always has Redis in the stack.

Why it matters

Redis makes a stack measurably better when used at the right points. Three reasons why Redis is mandatory in the SME stack in 2026.

First: latency. Redis operations are typically under 1 millisecond, often in the microsecond range. PostgreSQL queries even on indexed tables take 5-20 ms. A session lookup per request that drops from 15 ms (Postgres) to 0.3 ms (Redis) saves 1.5 seconds of CPU time at 100 requests per second. At 1000 requests per second, that is 15 seconds -- a server saved.

Second: rate limiting without database pressure. Whoever has a login endpoint wants to limit brute-force attempts. With a Postgres INSERT per request you block the DB under load. With Redis INCR + EXPIRE, a counter per IP is held that disappears automatically after the TTL -- clean mechanism, zero database load.

Third: pub/sub and job queues. Whoever wants to sync real-time notifications between backend instances (e.g. WebSocket messages in a multi-pod application) uses Redis PUBLISH/SUBSCRIBE. Whoever wants to execute background jobs (email sending, report generation, AI embedding) uses BullMQ or Sidekiq with Redis as queue. Both are very cumbersome without Redis.

License question 2026: stay on Redis (SSPL/RSAL) or switch to Valkey (BSD)? For most SME applications this does not matter -- SSPL bites only on reselling. But whoever wants to stay license-pure or has an OSS audit switches in 2026 to Valkey. Drop-in replacement, same wire protocol, same clients (ioredis, node-redis, redis-py). In Debian 13, Valkey is already default.

How it works

Redis is a single-threaded event-loop server (modulo I/O threading since version 6). The single-threaded architecture sounds like a bottleneck but is fast in practice: no lock contention, atomic operations without overhead, cache efficiency through sequential data access. A Redis node handles 100k-500k operations per second on modern hardware.

A minimal production setup with Node client (ioredis):

const Redis = require('ioredis'); const redis = new Redis({ host: 'redis.local', port: 6379, password: process.env.REDIS_PASSWORD, enableAutoPipelining: true });

// Session lookup await redis.set(`session:${sessionId}`, JSON.stringify(userData), 'EX', 3600); const data = JSON.parse(await redis.get(`session:${sessionId}`));

// Rate limit per IP const count = await redis.incr(`rate:${ip}`); if (count === 1) await redis.expire(`rate:${ip}`, 60); if (count > 100) throw new Error('Rate limit exceeded');

// Job queue with BullMQ const queue = new Queue('emails', { connection: redis }); await queue.add('send', { to: '[email protected]', subject: 'Invoice' });

Persistence: two options. RDB (snapshot) writes the whole DB periodically to disk -- fast, but on crash you lose changes since the last snapshot. AOF (append-only file) logs every write operation -- slower but RPO under 1 second. For sessions and caches RDB suffices; for job queues and critical data combine AOF + RDB.

Replication: master-replica setup with asynchronous replication. Redis Sentinel monitors and does auto-failover, Redis Cluster shards automatically across multiple nodes. For SMEs with < 100k ops/s, a single master with one replica for failover suffices -- cluster is usually overkill.

Monitoring via redis_exporter for Prometheus, plus Redis INFO command for connection count, memory usage, hit/miss ratio. Key alert: memory > 80 percent, slow-log entries > 100 ms.

For AI applications: RediSearch + RedisVL offer vector search with HNSW index. Performance is good for < 1M vectors, but specialized DBs (Qdrant, pgvector) still lead in 2026 benchmarks at high filter complexity.

Redis/Valkey to production in 5 steps

1. 01Decide Redis vs. Valkey: for new setups Valkey 8.0 under BSD, for existing stacks continue with Redis -- switch possible without code changes.
2. 02Set up Docker container with persistence: AOF + RDB combined for job queues, only RDB for pure caches. Set requirepass in config, bind to 127.0.0.1 or Docker network.
3. 03Connect application: ioredis (Node), redis-py (Python), aioredis (async Python), Spring Data Redis (Java). Enable connection pool with auto-pipelining.
4. 04Define key conventions: namespace:type:id (e.g. user:session:abc123). Set TTL per key pattern. EXPIRE is mandatory for all sessions and rate-limit counters.
5. 05Wire monitoring: redis_exporter for Prometheus, Grafana dashboard with memory usage, connection count, hit/miss ratio, slow log. Alert at memory > 80 percent.

When to use Redis (or Valkey)

The right choice when (a) sessions, rate limits, or caches with microsecond latency are needed, (b) pub/sub mechanics for backend-backend communication is required, or (c) job queues with BullMQ/Sidekiq/Bull worker should be set up.

Concrete scenarios: Express/Fastify application with session cookies (Redis store instead of in-memory), login endpoint with rate limiting (Redis INCR), background email sending via Brevo SMTP (BullMQ queue with Redis), real-time notifications via WebSocket hub (Redis pub/sub as broker between pods), cache in front of expensive LLM API calls (Redis as KV cache with TTL).

New 2026 use cases: LiteLLM cache layer for LLM responses (often 80 percent cache hit on repeated queries), AI agent state management (Redis streams for tool calls), workflow orchestration with Temporal/Inngest (Redis as coordination layer).

License recommendation: for new setups in 2026 -> Valkey 8.0 under BSD. Existing Redis stacks stay on Redis without problems, since SSPL is no obstacle for internal use. AWS ElastiCache and Azure Cache both offer Valkey as an option.

When not to use

Never as primary DB for business-critical data. Redis is in-memory-focused; persistence is an option, not the default. On a server crash between AOF sync and before RDB snapshot, current writes are lost. Client data, contracts, invoices belong in Postgres -- Redis as cache in front.

For very large data volumes (> 100 GB): Redis needs correspondingly much RAM. A 200 GB cache data set needs a 200 GB+ RAM server, which is expensive. Here disk-based caches like Memcached (still alive in 2026) or hierarchical caches with hot data in Redis and cold data in Postgres pay off.

For permanent data without TTL: whoever stores all entries without expiry builds a growing in-memory DB -- not the Redis use case. Standard is: set TTL, or after expiry recompute from source of truth (Postgres).

For complex queries with joins and aggregates: Redis is a KV store, not a relational DB. Whoever needs complex reports belongs in Postgres or ClickHouse.

For multi-region setups with global consistency: Redis replication is asynchronous, cluster is primarily for scaling. Anyone needing real multi-region consistency looks at CockroachDB or distributed caches.

Trade-offs

FAQ

Related topics

Sources

1. Redis 8 release notes · 2026-05
2. Valkey 8.0 documentation - BSD fork of Redis · 2026-05
3. Redis Source Available License (RSALv2) and SSPL · 2026-04
4. RediSearch vector search documentation · 2026-05