Redis clients and data structures

Redis is an in-memory data store with simple structures (strings, hashes, lists, sets, sorted sets). It is used for caches, sessions, counters, rate limits, queues and locks because every operation is fast and atomic.

A mental model

A whiteboard next to the desk. Reads and writes take no time, and everyone in the office sees the same board, but if the power goes out the writing may be gone unless you copy it somewhere permanent.

How it works

Spring RedisTemplate and StringRedisTemplate expose each data type through opsForValue(), opsForHash(), opsForList() and so on: ops.set("session:42", json, Duration.ofMinutes(30)).

Lettuce (default in Spring) and Jedis are the client libraries. Lettuce shares one connection across threads; Jedis needs a pool because each connection is not thread safe.

Keys should have a clear naming scheme and almost always a time to live (TTL). Without it, memory fills up with stale data.

Atomic commands (INCR, SETNX, ZADD) and Lua scripts make counters, locks and leaderboards safe under concurrency.

Going deeper

Choose the serializer on purpose. The JDK default writes binary Java objects that other languages cannot read and that break when the class changes; JSON or strings are more portable and debuggable.

Never run KEYS * in production: it blocks the single-threaded server. Use SCAN with a cursor.

Redis is a cache first. Persistence (RDB snapshots, AOF) reduces loss but does not make it a safe system of record unless you accept those trade-offs.

Under the hood

The server runs commands on one thread, which is why each command is atomic and why one slow command stalls everyone. Clients speak the RESP protocol over TCP and can pipeline many commands without waiting for replies, which is how Lettuce gets high throughput from a single connection.

Common mistakes

• Keys without TTL.
• Using KEYS in production.
• Default JDK serialization for shared data.
• Storing huge values or huge collections under one key.