EXPLAINER

Redis

Redis is an in-memory data store for keys with a few rich values: strings, lists, sets, sorted sets, and expirations. Applications use it for cache, rate limits, short-lived sessions and queues, not as the only copy of data they cannot lose.

Short answer: Redis keeps keys in memory with fast reads and expirations. Use it for cache, rate limits and short-lived coordination. Keep the system of record in PostgreSQL or another durable database.

What it is

Redis is a data store that keeps structures in memory and serves them over a simple protocol. The basic object is a key with a value: a string, a list, a set, a hash, a sorted set. Keys can expire (a TTL). The speed comes from memory and a model that avoids complex queries. Persistence to disk exists (snapshots and an append-only file) and is configurable. You should decide explicitly whether a restart may lose data.

Redis is not a relational database and not a document database for your system of record. It is a sharp tool beside PostgreSQL or similar. People also use it as a makeshift queue and as a pub/sub bus. Those uses work best when losing or duplicating a message is something you have thought about.

Why and when it is used

Use Redis when a value is derived and can be recomputed: a cache of a rendered page fragment, a session that can be re-authenticated, a rate-limit counter, a feature flag snapshot. Use it for coordination: a lock with an expiry so two workers do not run the same job, a short-lived token. Use sorted sets for leaderboards or "next items by timestamp" if the data fits in memory.

Do not use Redis as the only store of orders or user profiles unless you have configured persistence, backups and a restore drill and you accept the operational model. If you cannot rebuild the data from the system of record, it does not belong only in Redis. Do not use it because every architecture diagram had a box labelled cache.

How it works

Clients send commands (GET, SET, INCR, EXPIRE). A single command is atomic. Several commands are not, unless you use a transaction or a Lua script. The classic rate limiter is INCR on a key with an expiry: the value is the count in the window. If the process crashes and you had no persistence, the counters reset, which for rate limits is often fine.

Eviction policy decides what happens when memory is full: refuse writes, or drop keys. A cache should be allowed to drop keys. A store of jobs might not. Pub/sub delivers messages to current subscribers and does not keep them; if you need a queue that survives a consumer restart, look at streams or a real queue, and know the delivery guarantees. Redis Cluster shards keys across nodes; keys that must be updated together need the same slot, which is a design constraint.

Technologies and dependencies

A Redis server or a managed equivalent, a client library, and a memory budget. Docker is fine for local use. The application should have timeouts on every command so a stuck Redis does not stall every request forever. Environment Variables hold the URL and the password. Production Redis should not be open to the internet without authentication and a private network. Name keys with a prefix (app:ratelimit:user:123) so a shared instance is debuggable.

How to get started

  1. Run Redis locally. Set a key with a 30-second TTL and read it. Wait and read again.
  2. Implement a tiny rate limit: increment a key per user id per minute. Return a fake 429 when it passes 5. Call it in a loop.
  3. Restart Redis and see the key disappear if you did not turn persistence on. Decide if that is acceptable.
  4. Add a timeout in the client. Stop Redis and confirm the app fails fast rather than hanging.
  5. Only then cache something expensive. Measure hit rate. A cache you never hit is complexity.
  6. Document which data is safe to lose.

If the next idea is "store the shopping cart only in Redis" and the cart is revenue, write down the persistence and backup plan before you ship.

Cautions and trade-offs

Memory is the capacity plan. A key per user with a large JSON value will exhaust RAM and then eviction will delete something you needed. Name TTLs deliberately; a cache without expiry is a leak.

KEYS * on a production instance can stall it. Use SCAN. Shared Redis with no key prefix and no ACL means one app deletes another's keys. Managed Redis with a tiny memory cap and an aggressive eviction policy will make a cache look "randomly empty". And a distributed lock in Redis is subtler than a blog post. If the lock expires while the worker is still running, two workers proceed. Use locks for coordination you can tolerate being wrong, or study the failure mode before you use them for money.