In a cache-aside deployment, an attacker (or a buggy client) repeatedly requests keys that are known not to exist in the database, e.g. random or sequential IDs. Since a cache-aside cache only stores things that were successfully loaded, why does this traffic pattern hit the database on every single request, and what technique addresses it?

## Why a miss never gets cached Cache-aside, by construction, only ever populates the cache after a successful load from the database — the miss-then-populate flow described by the core pattern assumes the database lookup returns a real value to cache. When a client repeatedly requests a key that does not and will never exist in the database (a bogus user ID, a guessed order number, a randomly generated key from an attacker probing the system), every single request for that key follows the same path: 1. cache miss, 2. database query, 3. database returns "not found," 4. and — critically — nothing gets written into the cache, because there's no value to cache. The next request for that exact same nonexistent key repeats the identical cycle from scratch. This is called **cache penetration**: traffic that structurally cannot benefit from caching at all under a naive cache-aside implementation, because the cache only ever remembers hits, never misses. ## Why it matters This matters because it defeats the entire purpose of putting a cache in front of the database for that traffic pattern — the cache adds latency and complexity but provides zero load reduction for these requests, and if the request rate is high it can drive real, sustained load straight through to the database exactly as if there were no cache at all. That rate can be: - **organic**, like a broken client retrying a typo'd ID in a loop, or - **malicious**, like an attacker enumerating IDs specifically because they've noticed the cache doesn't shield the database from misses. It's a favorite vector in security write-ups precisely because it's cheap for an attacker to generate: no valid credentials or complex payloads needed, just a stream of plausible-looking but nonexistent keys. ## The standard fix — negative caching The standard fix is **negative caching**: when the database lookup for a miss comes back empty, the application caches that fact too — writing a small sentinel/tombstone value (e.g. a literal marker like `__NULL__`, or a JSON `{"exists": false}`) under the same key, usually with a shorter TTL than a normal positive entry. The next request for that same nonexistent key now hits the cache, sees the tombstone, and can return "not found" immediately without ever touching the database — converting what used to be guaranteed database traffic into an ordinary cache hit, just one that represents absence rather than presence. ## What negative caching costs Negative caching isn't free. - **Why the shorter TTL.** It uses a shorter TTL specifically because a "not found" result is more likely to flip (a record gets created later) than a "found" result is to change identity, and a stale negative entry means a newly-created record appears to not exist for up to that TTL window — annoying for a user who just signed up and immediately can't be found by their own new ID. - **It opens a new, smaller attack surface of its own.** If key space is unbounded (e.g. arbitrary strings), an attacker can still exhaust cache memory by generating enough distinct nonexistent keys to fill the cache with tombstones, which is why negative-cache TTLs are kept short and sometimes rate-limited. ## The outer guard — a Bloom filter A complementary technique used alongside or instead of negative caching, especially when the key space is huge and enumeration is a concern, is a **Bloom filter**: a compact, probabilistic structure built from all known-valid keys that can answer "definitely not present" or "possibly present" before ever touching the cache or database — a lookup that gets a definite "not present" from the Bloom filter is rejected immediately with no cache or database round trip at all, while only genuinely plausible keys proceed to the normal cache-aside path. This exact combination — cache-aside plus negative caching plus a Bloom filter as the outer guard — comes up repeatedly in large-scale system design discussions for services like URL shorteners and content platforms that are directly exposed to enumeration attempts, because the cost of a single unguarded miss-path query is cheap, but the cost of a sustained flood of them is not.