Redis

What is Redis and what does it do?

Redis is an in-memory data store reached through commands rather than general-purpose SQL. Values are not limited to opaque strings. Hashes, lists, sets, sorted sets and streams provide operations that match common application needs directly.

Keeping the active dataset in memory makes short command paths possible. Redis can also replicate data and persist it according to the selected durability model. Those capabilities do not make every value equally durable, so the purpose and lifetime of each key must be explicit.

The data type shapes the operation

Choosing a Redis type is part of modeling the problem:

Need	Suitable structure	Useful property
Expiring session fields	Hash	Several named fields under one key
Unique membership	Set	Atomic membership tests
Ordered scores	Sorted set	Ranking and range queries
Append-only events	Stream	IDs, consumer groups and acknowledgements

A structure should be selected for the operations it supports, not only for how the data looks in a debugger. Flattening every value into serialized text removes many of the atomic operations that make Redis useful.

Expiration and persistence answer different questions

Expiration defines how long a key is allowed to exist. It is part of the data model for caches, temporary tokens and sessions. Eviction is different: it is a memory policy that may remove keys when configured limits are reached.

Persistence answers what survives a restart. Redis supports snapshot-based persistence, append-only logging, a combination of both, or no persistence. Each option changes write cost, recovery time and the amount of recent data that may be lost. Replication improves availability but does not replace an independent backup and recovery decision.

The source of truth must stay visible

Redis is a strong fit when at least one of these statements is true:

• The value can be rebuilt from another authoritative source.
• The operation maps naturally to an atomic Redis command.
• Expiration is intentional and tested.
• Removing a slower round trip has a measured benefit.

It is a weak fit when ownership is unclear or when permanent business records are written without a defined durability and recovery model. Distributed locks and queues also require failure analysis beyond a successful command. Low latency is valuable, but it does not replace consistency, capacity planning or observability.