A Redis instance reaches the `maxmemory` limit configured in its config file, and the deployment never changed `maxmemory-policy` from its default. What happens to the commands clients send after that point, and what error do they see?

## What `maxmemory` is `maxmemory` is a configuration directive giving Redis a byte budget for the data it holds, e.g. `maxmemory 4gb`. It is a soft accounting limit, not an OS-enforced one: Redis compares its own `used_memory` figure against the limit before executing commands that can allocate. The accounting deliberately subtracts some transient buffers (replica output buffers, the AOF buffer), so the process RSS you see in `top` is normally **larger** than `maxmemory` — that gap matters when you size a container. On 64-bit builds the default is `maxmemory 0`, meaning "no limit". An instance with no limit cannot OOM-error; it simply keeps allocating until the kernel's OOM killer terminates it or the box starts swapping, at which point latency collapses because Redis touches memory on every command. Setting a limit is therefore the first production step, not an optimization. ## What happens at the limit When used memory reaches `maxmemory`, Redis consults `maxmemory-policy`. The default value is **noeviction**, which means: delete nothing, refuse to grow. Concretely, every command is tagged in the command table with a `denyoom` (use-memory) flag. Before executing a `denyoom` command while over the limit, Redis returns the error reply: `(error) OOM command not allowed when used memory > 'maxmemory'.` Commands without that flag run normally. So: - **Still works:** GET, MGET, EXISTS, LRANGE, HGETALL, TTL, SCAN, INFO, and all read paths. - **Still works:** DEL, UNLINK, LPOP, SPOP, EXPIRE, LTRIM — anything that frees or cannot grow memory. - **Fails:** SET, SETEX, INCR, LPUSH, HSET, SADD, ZADD, XADD, RPOPLPUSH's push side, and any script or MULTI containing them. Because TTL'd keys keep expiring in the background, memory can drop back under the limit on its own; writes then start succeeding again. Clients experience this as a flapping stream of OOM errors rather than a hard outage, which is why the condition is often misdiagnosed as a network or client-library bug. ## Why noeviction is the default Redis is used both as a cache and as a system of record for things like sessions, queues and dedupe sets. Silently deleting a user's session or a queued job to make room for a cache entry would be a data-loss bug, so the shipped default fails loudly instead. Choosing an eviction policy is an explicit statement that *everything in this instance is disposable* (`allkeys-*`) or that *only the keys I gave a TTL are disposable* (`volatile-*`). ## Diagnosing it `INFO memory` gives `used_memory`, `used_memory_rss`, `maxmemory`, `maxmemory_policy` and `mem_fragmentation_ratio`. `INFO stats` gives `evicted_keys` — under noeviction it stays at 0 no matter how bad things get, so a zero counter is not evidence of health. Client-side, count OOM errors: a well-behaved application should surface them as a distinct metric rather than as generic "redis error", because the remediation is completely different from a timeout. ## Fixing it There are only four real moves, in rough order of preference: 1. **Give the data TTLs** and switch to a `volatile-*` policy so genuinely disposable data is reclaimed. 2. **Declare the instance a pure cache** and switch to an `allkeys-*` policy. 3. **Shrink the data** — bad key design (giant hashes, unbounded lists, oversized serialized blobs) is usually the actual cause. 4. **Raise `maxmemory` / add nodes**, keeping headroom below the container limit for fragmentation, client buffers and fork copy-on-write during RDB/AOF-rewrite. Note that changing policy is live: `CONFIG SET maxmemory-policy allkeys-lru` takes effect immediately and Redis starts evicting on the next command that needs room — a useful emergency lever, but only if you are certain nothing in the keyspace is irreplaceable. Persist the change to the config file (or `CONFIG REWRITE`) or it vanishes on restart.