# 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.