Redis is the Swiss-army knife of the backend — in-memory, single-threaded, microsecond latency. Main uses:
1 · Caching
- Cache expensive query results and computed values. Always set a TTL — an unbounded cache is a memory leak waiting to happen.
- Cache-aside is the default pattern: on read, check Redis → miss → load from DB → write to Redis → return.
- Invalidation is the hard part. Prefer short TTLs + write-through for data that must stay fresh; accept slight staleness elsewhere.
- Guard against stampedes: when a hot key expires, many requests hit the DB at once. Mitigate with a short lock, "early recompute," or jittered TTLs.
2 · Rate limiting
- Fixed-window counter:
INCR key + EXPIRE. Simple, but bursty at window edges.
- Sliding window / token bucket via a small Lua script for atomicity and smoother limits. Good fit for protecting LLM API budgets and per-user quotas.
3 · Distributed locks
SET key value NX PX 30000 — acquire only if absent, with an expiry so a crashed holder doesn't deadlock forever.- Release safely with a Lua compare-and-delete (only delete if the value is still yours).
- For correctness-critical locking across nodes, understand Redlock's trade-offs — and prefer Postgres advisory locks or Temporal when correctness matters more than speed.
4 · Queues & streams
- Lists (
LPUSH/BRPOP) for a simple work queue.
- Redis Streams (
XADD/XREADGROUP) for consumer groups, acks, and replay — a lightweight alternative to Kafka for moderate volume.
- For Python, this underpins Celery/RQ/Dramatiq brokers.
5 · Sessions & ephemeral state
- Session stores, feature-flag caches, "user is typing" / presence, leaderboards (sorted sets
ZADD/ZRANGE).
Operational notes
- It's in-memory: set
maxmemory + an eviction policy (allkeys-lru for a pure cache). Decide consciously what happens when memory fills.
- Persistence (RDB/AOF) exists but treat Redis as a cache/coordination layer, not your source of truth. The durable record lives in Postgres.