Redis

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.