Redis: When, Why, and When Not

Redis is an in-memory data platform useful for shared low-latency state with explicit expiry or replay semantics. SupportDesk AI may use it for cache entries, rate limits, token quotas, job coordination, streams, and ephemeral progress. PostgreSQL remains the durable system of record; the application must remain correct when Redis is flushed or unavailable.

What will you be able to do?

• decide whether Redis solves a measured requirement;
• run it locally with safe network binding;
• design tenant-safe keys, TTLs, and invalidation;
• evaluate cache, rate-limit, stream, queue, and lock tradeoffs.

When should Redis be added?

Add it only if at least one requirement is measured and PostgreSQL or process memory is not adequate:

• repeated expensive reads need a shared cache;
• a rate/usage limit needs atomic counters with expiry;
• multiple workers need short-lived progress or pub/sub;
• a selected job system requires Redis;
• a stream needs bounded replay and consumer groups;
• best-effort coordination benefits from leases.

Do not add Redis merely to store sessions, JSON, embeddings, or every object “for speed.” Every new data system adds security, backup, capacity, monitoring, and failure work.

How do you run and access it?

Bind local development to loopback, require authentication outside isolated development, enable TLS where supported, use ACLs, and never expose Redis to the public internet.

Version tags are examples; consult current supported releases before production.

Use namespaced, non-PII keys such as:

How should cache-aside work?

1. Read the cache.
2. On miss, read PostgreSQL with authorization.
3. Serialize a versioned safe view.
4. Cache with a TTL and jitter.
5. On write, commit PostgreSQL first, then invalidate or update the cache.

Cache keys must include tenant and authorization-sensitive variation. Never cache a response under a key that omits permissions. Decide whether failure should fail open (serve from PostgreSQL) or fail closed (security quota) for each feature.

What about locks and queues?

A Redis lease expires; a paused owner may resume after another owner acquired it. Use fencing tokens when a downstream resource must reject stale owners, or prefer database constraints for durable exclusivity. For queues, document delivery guarantees, acknowledgment, retries, dead-letter behavior, ordering, observability, and what survives a Redis failure.

Why does this matter in AI-native systems?

Redis can enforce fast per-tenant token/request budgets and distribute streaming progress. It must not be the only record of an AI run, approval, tool effect, or billed usage. Write durable outcomes to PostgreSQL and reconstruct ephemeral state after failure.

Common mistakes

• No TTL creates unbounded memory use.
• KEYS * blocks large production instances; use scans and designed key indexes.
• Cache stampede sends every miss to PostgreSQL or a model; use jitter and controlled single-flight.
• Rate limit trusts client-provided tenant identity.
• Redis persistence is mistaken for the business backup strategy.
• Model response cache ignores prompt/schema/model/tenant versions.

AI Pair-Programmer Prompt

Exercise

Design a per-tenant, per-user sliding-window limit for AI drafts plus a cache for public ticket summaries. Explain different failure behavior for each.

Acceptance criteria: atomic tests cover the boundary second, keys never collide across tenants, memory is bounded, cache outage falls back safely, and quota outage follows a documented security policy.

Knowledge check

1. Which database owns tickets and approvals?
2. Why add jitter to cache TTLs?
3. Is a Redis lease permanent proof of ownership?
4. What must a model-response cache key include?

---

Answers

1. PostgreSQL.
2. To prevent many entries expiring simultaneously and causing a stampede.
3. No; expiry and partitions allow stale owners, so use fencing or stronger invariants.
4. Tenant/access scope plus input, prompt, schema, model, and relevant policy versions.

Completion checklist

• Every Redis use has a measured reason.
• Keys, TTLs, bounds, and failure modes are documented.
• The system remains correct after Redis loss.

Primary references

• Redis data types
• Redis security
• Redis eviction