Why does Django's LocMemCache backend give inconsistent results once a site runs under several worker processes?

## How LocMemCache stores data `django.core.cache.backends.locmem.LocMemCache` is Django's **default** cache backend. Its data lives in three module-level dictionaries inside `locmem.py`, one set per `LOCATION` name: - a `_caches` dict holding an ordered dict of pickled values, - an `_expire_info` dict holding each key's expiry timestamp, - a `_locks` dict holding a `threading.Lock` per store. Every `LocMemCache` instance created for the same `LOCATION` in the same Python process points at the same ordered dict. That is why the docs call it **thread-safe**: threads inside one process share the store, and the lock serialises access. When the store grows past `MAX_ENTRIES` (default `300`), it culls entries using a least-recently-used ordering. ## Why processes break it A Python module-level variable exists once **per interpreter process**. Production servers normally run several **worker processes** so they can use several CPU cores and survive a crashed worker. Each worker imports Django separately, so each has its own `_caches` dict. Nothing synchronises them. Picture four workers behind one socket: 1. A request lands on worker 1, misses, computes the value and calls `cache.set()`. Only worker 1's dict now holds it. 2. The next three requests land on workers 2, 3 and 4. Each misses and recomputes. 3. An editor saves a change; the save path calls `cache.delete()` on worker 3. Workers 1, 2 and 4 still hold the old value and keep serving it until `TIMEOUT` (default `300` seconds) runs out. ## The symptoms you see in production | Symptom | Cause | |---|---| | Page shows old data for some users, new data for others | Invalidation reached only the worker that ran it | | Cache hit rate much lower than expected | Each worker warms its own copy | | Memory grows with worker count | The same entries are stored once per process | | Rate limits or counters are too generous | `incr()` updates a per-worker counter | | "Works on runserver, fails in production" | The development server runs one process | The last row is the classic interview hook: `runserver` runs a single process, so the bug never appears locally. ## What to use instead The fix is a backend whose storage lives **outside** the Python process, so every worker on every machine reads and writes the same entries: - **`RedisCache`** or **`PyMemcacheCache` / `PyLibMCCache`**: a cache server shared by all workers and all hosts. - **`DatabaseCache`**: a table in the project database, shared by everything that connects to it; slower, but needs no extra service. - **`FileBasedCache`**: files in a directory, shared only by processes that can see that directory, so usually by one machine. ## Confirming the diagnosis Before changing backends, prove that the per-process store is the cause: 1. Check what is actually configured: in `manage.py shell`, `from django.core.cache import caches` and print `type(caches["default"])`. A project that never set `CACHES` is running `LocMemCache` without anyone having chosen it. 2. Count processes: look at how many worker processes the application server starts, and on how many hosts. 3. Reproduce with two processes locally: start the application server with two workers instead of `runserver`, set a value through one request and read it through repeated requests; roughly half will miss. 4. Watch the symptom correlate with worker identity: log the process ID next to cache hits and misses, and stale reads will cluster on the workers that did not run the invalidation. If the stale reads persist after switching to a shared backend, the cause lies elsewhere, for example in whole-page caching or in HTTP caches outside Django, which are separate topics. ## When LocMemCache is still the right choice - **Development and tests**, where one process runs and isolation between test runs is welcome. - **A deliberate per-process memo** for data that never changes while the process lives and is cheap to rebuild, declared as a second alias with its own `LOCATION` so it is obviously not the shared cache. - **Single-process deployments**, where there is only one copy anyway. Two subtleties worth stating in an interview: - Two `LocMemCache` aliases that share a `LOCATION` (including the empty default) share one store inside a process; give each a distinct name to keep them apart. - Threads do **not** cause the problem. A single process with many threads sees one consistent store; only separate processes diverge.