One Redis instance holds both a disposable read cache and data the application cannot regenerate — login sessions, a dedupe set, and a pending-job list. How do you set `maxmemory` and `maxmemory-policy` for it, and what would you change about the architecture?

## Why this is a design question, not a config question `maxmemory-policy` is a property of the **instance**, not of a key. When one instance holds two data classes with opposite requirements, no value of that single setting is correct: | Policy | Cache under pressure | Sessions / queue | |---|---|---| | `allkeys-lru` / `allkeys-lfu` | degrades gracefully (misses) | **silently deleted — data loss** | | `noeviction` | writes fail, cache cannot grow | protected, but **every write path errors** | | `volatile-*` | evicts only TTL'd keys | protected **if** they truly have no TTL | Recognizing this trilemma is most of the answer. The rest is what you do about it. ## The single-instance compromise If you must stay on one instance today: 1. **TTL discipline.** Every cache key gets an expiry; durable keys never do. This is not a convention to document, it is a rule to enforce in code — a cache client whose `set` signature *requires* a TTL, so an untagged cache write is impossible to express. One forgotten TTL is one un-evictable key growing forever. 2. **Policy `volatile-lru`** (or `volatile-lfu` if batch scans pollute recency). Only the TTL'd cache is evictable. 3. **Monitor the eviction pool.** `INFO keyspace` reports `keys=` and `expires=` per database. If the volatile share shrinks, you are drifting toward the failure where Redis has no candidates and reverts to OOM errors — the same outage `noeviction` would have given you, but arriving later and less predictably. 4. **Alert on the durable set's absolute size**, not just total memory. Sessions and queue depth growing is a capacity signal that eviction will never relieve. 5. **Consider key-prefix separation plus `--bigkeys`/memory sampling** so you can attribute memory to each class and forecast when the split becomes mandatory. ## The architecture change Split by data class: - **Cache instance:** `allkeys-lfu` (or `-lru`), persistence often off or RDB-only, sized for hit rate, replicas optional, cheap to lose entirely. Losing it costs backend load, not correctness. - **State instance:** `noeviction`, AOF persistence with a chosen fsync policy, replicas plus failover, alerting long before the memory limit. Here an OOM error is the *correct* behavior: a loud back-pressure signal, not a bug. The split also decouples operations: you can flush, resize, restart or reshard the cache freely; you cannot do any of that to sessions. Blast radius separation is often a stronger argument than the eviction policy itself. A further question worth asking: does the pending-job list belong in Redis at all? A list used as a work queue with at-most-once semantics is a durability decision disguised as a data-structure choice. That may be fine — with AOF and replicas, and with jobs that are cheap to lose — but it should be a decision someone made, not a consequence of the cache instance being convenient. ## Sizing `maxmemory` `maxmemory` is compared against Redis's own `used_memory` accounting, which excludes replica output buffers and the AOF buffer, and it cannot know about allocator fragmentation. Real RSS is routinely 1.2–1.5x the configured limit, and more transiently: - **Fragmentation** — check `mem_fragmentation_ratio`; workloads with many differently-sized values fragment worse. `activedefrag` can help but costs CPU on the command-processing thread. - **Client output buffers** — a slow consumer of a big `LRANGE` or a Pub/Sub subscriber can accumulate hundreds of megabytes; `client-output-buffer-limit` bounds it. - **Replication backlog** — sized by `repl-backlog-size`, held whether or not a replica is attached. - **Fork copy-on-write** — during an RDB save or AOF rewrite, pages modified by the parent are duplicated. A write-heavy instance can add a large fraction of the dataset transiently; this is the classic cause of an OOM-kill on a box that "had plenty of room". A workable rule: set `maxmemory` around 60–70% of the container limit for a write-heavy persisted instance, closer to 75–80% for a read-heavy cache with persistence off. Then verify with `used_memory_rss` under real traffic including a background save, rather than trusting the arithmetic. ## What good sounds like in an interview Name the trilemma explicitly; refuse the false premise that a policy exists which protects sessions and bounds the cache simultaneously; give the compromise you would ship today and the split you would drive to; and show you know `maxmemory` is not the process's memory ceiling. Mentioning the fork copy-on-write spike and the `expires`-share monitor is what separates a designed answer from a recited one.