Refuse the write, keep the record.

maxmemory-policy answers one question: when the keyspace reaches maxmemory and a write arrives, what gives? The cache policies sacrifice a stored key so the write can succeed; noeviction sacrifices the incoming write so no stored key is touched. That single choice is the line between a cache and a system of record.

• allkeys-lru / allkeys-lfu — evict from the whole keyspace by least-recently-used (or least-frequently-used) approximation. A write past the cap deletes the coldest key, then succeeds. Right for a pure cache: every value is reconstructable, so a drop costs a miss, not a record.
• volatile-lru / volatile-ttl / … — evict only keys that carry a TTL, by the named rule (volatile-ttl takes the shortest remaining life first). Keys with no expiry are immune; if the keyspace fills with non-volatile keys, these behave like noeviction.
• noeviction — evict nothing. A write that would exceed maxmemory is rejected with an OOM error; reads still serve; the data already stored is never touched.

The cache policies keep serving by forgetting; noeviction keeps the truth by refusing. A system of record cannot afford to forget, so it accepts the refusal as the cost of never losing a record.

Put the same write — a new job row at a full keyspace — to two servers, one on allkeys-lru and one on noeviction, and the divergence is the whole lesson. Under allkeys-lru the write succeeds, but to make room the server deletes the key it judges coldest. If that key was the only copy of a record, it is gone — silently, with nothing in the response to say so. Under noeviction the write fails with an OOM error, nothing stored is lost, and the alert fires on used_memory crossing the threshold.

EchoMQ's job row has no second canonical copy. The enqueue script writes the row in one atomic step — HSET emq:{q}:job:<JOB-id> state pending attempts 0 payload <body> — and claim / complete / retry mutate that same HASH. There is no shadow row in Postgres to fall back on if the key disappears. That is why EchoMQ's Valkey runs noeviction: an evicted job key is a lost job, and a queue that silently drops keys is a queue that silently loses work.

Two design choices ride alongside it. First, maxmemory is a guardrail set far above the working set, not a working ceiling — the live dataset is single-digit megabytes, so 512 MB leaves roughly half the box for fork copy-on-write and buffers, and the cap exists to turn a runaway into an alert long before the OOM killer acts. Second, propagation-error-behavior panic makes the server fail a write rather than acknowledge data that may not survive — the same posture as noeviction, applied to propagation rather than to memory: refuse, do not pretend.