web_sport/docs/adr/0010-redis-is-a-cache-and-an-ephemeral-store-never-a-system-of-record.md

ADR-0010: Redis is a cache and an ephemeral store, never a system of record

• Status: Accepted
• Date: 2026-08-11

Context

Redis is fast and tempting. Once a cart or an order lives only in Redis, an eviction or a restart becomes lost revenue.

Decision

Everything in Redis must be either reconstructible from PostgreSQL or genuinely disposable. Current uses: catalog read caching, guest carts, OTPs, password-reset tokens, rate limit counters, checkout stock reservations and idempotency keys.

The local container runs --maxmemory-policy allkeys-lru with persistence off — an explicit statement that eviction is always preferable to refusing writes. RedisService.getOrSet swallows cache read and write failures and falls through to the source, so a Redis outage degrades latency rather than availability.

Every key is built in cache-keys.ts; no ad-hoc key strings anywhere.

Consequences

Redis can be flushed at any moment and the store keeps working. Guest carts are the one place where loss is user-visible, which is why they are promoted to PostgreSQL at sign-in and carry a 30-day TTL.

Stock reservations need care: they are held in Redis with a TTL, but the authoritative reserved count is a PostgreSQL column, so an eviction cannot silently oversell.

Alternatives considered

Redis as primary store for carts — rejected: the failure mode is losing a customer's basket. In-memory caching in the Node process — rejected: it does not survive a restart and cannot be shared across instances.