Redis persistence (RDB and AOF) and eviction policies

Every exhibit sits on the store's shelves, and nothing is kept anywhere else.

At the evidence store	In Redis
the quarterly audit photographs every shelf; after a fire the photographs show the store as it was then	an RDB snapshot and what a crash loses (steps 2–3)
the officer closing up properly photographs the shelves first; a fire takes no photograph	a clean stop saves, SIGKILL does not (step 4)
the custody book records each exhibit in and out as it happens, and replaying it rebuilds the store	the AOF (step 5)
the shelves are full	maxmemory (step 7)
the hatch refuses anything that might need more shelf space	noeviction (step 8)
a clear-out destroys whatever has sat untouched longest	allkeys-lru (step 9)
a clear-out may destroy only exhibits already given a disposal date; with none dated, the hatch can only refuse	volatile-* (step 10)
counterfeit goods awaiting routine destruction share the shelves with evidence for open cases, under one clear-out rule	one instance, one policy (step 11)

In real terms: for each Redis you run, write down what a restart must bring back and what may be deleted when it is full; if two kinds of data give different answers, they need two instances.

Breaks down when: destroying an exhibit takes a signed form; Redis evicts a key silently, and only a counter moves.

Contrasting case: a pure cache that can be refilled from Postgres needs neither persistence nor noeviction: losing any key costs one miss.

4.1 ExamHall: the queue that shared the cache's policy

EXH-5020: at ExamHall's 09:00 exam start the question cache and the BullMQ grading queue shared one Redis running allkeys-lru. The cache's writes filled memory, and Redis evicted the grading jobs' keys to make room. MR !5320 gives the queue its own Redis with noeviction and leaves the cache on allkeys-lru.

4.1 EXH-5020 one Redis, allkeys-lru: 200 grading jobs, then 60000 question-cache writes · cache writes refused 0 · grading jobs kept 0 of 200
4.1 MR !5320 queue Redis (noeviction) + cache Redis (allkeys-lru): the same writes · cache writes refused 0 · grading jobs kept 200 of 200
4.1 MR !5320 20000 more jobs into the full queue Redis · added until it was full · refused with an OOM error the rest · other errors 0 · the first 200 jobs kept 200 of 200

Every grading job was gone and no write was refused, so nothing reported an error. After the split, the jobs survive the same writes, and a producer that overfills the queue's Redis gets an OOM error instead (steps 11–12).

4.2 Payments ledger: no cap in a 64 MB container

A ledger's FX-rate cache runs in a container limited to 64 MB, first with no maxmemory, then with maxmemory 40mb and allkeys-lru.

4.2 payments ledger FX cache in a 64 MB container, no maxmemory (0, the default): 200000 writes · kernel OOM kills 1 · new redis-server process yes · keys afterwards none
4.2 payments ledger FX cache in a 64 MB container, maxmemory 40mb, allkeys-lru: 200000 writes · kernel OOM kills 0 · new redis-server process no · keys afterwards some

With no cap, the kernel killed Redis and the restarted process came back empty; with a cap below the container's limit, Redis evicted keys and kept running (steps 7, 13).