Caching with Redis

Deleting is the safest default: the next reader reloads from the database. Overwriting with a fresh TTL restarts the clock, so a hot key's expiry never fires and a wrong value can live forever. Overwriting while keeping the remaining TTL keeps a hard age bound.

Delete the cached key rather than overwriting it, and delete only after the database transaction commits. Deletion is idempotent, so racing writers cannot leave a wrong value stuck until the TTL expires. The cost is one extra miss.

A hot key is one key taking a hugely disproportionate share of traffic. Because a key's name determines exactly one shard, and that shard executes commands on one thread, the load cannot be spread by adding nodes — one key saturates one CPU core and one network link.

When a popular key expires, every concurrent request gets nil from GET and all of them recompute the same value against the database at once. The number of duplicate recomputes is roughly request rate times recompute latency, and the resulting slowdown makes the window longer.

Start from how stale the data may be for the business, then check it against origin load: with N cached keys and TTL T, expiries alone push roughly N/T refetches per second. Shorten for volatile or sensitive data, lengthen when you also invalidate on write.

redis-cli --hotkeys scans the keyspace and reads each key's LFU access counter, so it only works when maxmemory-policy is an LFU policy (allkeys-lfu or volatile-lfu). Otherwise: OBJECT FREQ on suspects, brief MONITOR sampling, or counting keys in the application client.

On a miss, try SET lock:key <random token> NX PX <ttl>. The winner recomputes, writes the cache, then releases with a Lua script that deletes only if the stored value still equals its token. Losers serve stale, poll briefly, or degrade — they must not queue unbounded.

All the keys expire in the same second, so the origin sees one huge burst of misses and Redis a spike of expiry work. Add jitter — a random offset of roughly 10-25% of the base TTL per key — so expiries spread out over a window wider than the time to refill.

Use MGET with all 200 keys in one round trip. The reply is positional: nil in slot i means key i missed. Collect the missing ids, load them in one batched database query, then write them back — pipelined SETs or MSET plus expiries, since MSET cannot set TTLs.

Pick a format that is fast to encode/decode, compact, and tolerant of field additions — JSON for debuggability, a binary format like Protobuf/MessagePack for size and speed. Use a string when you always read the whole object; use a hash when you read or update individual fields with HGET/HSET.

It lets the application keep a copy of hot values in its own process memory and have Redis tell it when they change. After CLIENT TRACKING ON over RESP3, the server records which keys the connection read and pushes an 'invalidate' message listing keys the client must drop when they are modified, expired, or evicted.

Singleflight collapses concurrent misses for the same key inside one process, so 200 threads become 1 recompute per instance — free, instant, no network. It cannot see other instances, so 40 remain. A Redis lock collapses across instances to about one. Layer them: singleflight first, Redis lock second.

Fixed TTL bounds staleness: the entry dies at a known time no matter how often it is read. Sliding TTL (EXPIRE or GETEX on read) keeps popular entries alive but lets a continuously read key stay stale forever. Use sliding for idle timeouts, fixed for data freshness.

Use structured, prefixed keys with an embedded version: app:entity:v3:id. Bumping the version makes every old key unreachable and it dies on its own TTL, so a deploy that changes the serialized shape can never read an old-format value. For bulk drops, embed a generation counter you can increment.

The reader loaded the old row before the write committed, then wrote it back after the invalidation. Mitigations: keep TTLs short so damage is bounded; delete the key again after a short delay; write back with SET NX so a reader cannot clobber an entry a writer has already refreshed; or make the write-back conditional on a version stored with the value.

Default mode: the server remembers which keys each connection read and invalidates precisely — accurate, but it costs a bounded server-side table that can overflow. BCAST: the server remembers nothing per key and instead broadcasts invalidations for registered key prefixes — zero per-key memory, but clients receive messages for keys they never cached.

Invalidation is best-effort and asynchronous: there is a delivery window, a race where the value is cached after its invalidation was already sent, and total loss of messages while the connection is down. On reconnect the client must flush its entire local cache, since it cannot know what changed meanwhile. A local TTL and size cap are mandatory backstops.

Each replica is a separate process with its own core and network link, so N replicas roughly multiply read capacity for that one key. Check egress first: value size times reads per second. A write-hot key gains nothing and adds master work. A near cache is far cheaper.

You store N identical copies under different key names. Because the names hash to different slots, the copies land on different cluster nodes, and each reader picks one at random — so read traffic divides by N. You pay N times the memory, an N-key write fan-out that is not atomic, and a window where copies disagree.

Store the value with its recompute cost (delta) and a logical expiry time. On each read, refresh early if now - delta * beta * ln(random()) is past the expiry. Probability of refreshing rises near expiry and with cost, so usually one reader refreshes before anyone ever sees a miss.

Cache the miss: store an explicit not-found marker under the same key with a much shorter TTL than positive entries. Risks: the marker must be distinguishable from 'nothing cached', it must be deleted when the entity is created, and attacker-generated keys can flood memory.

Cache only measured-hot, read-mostly entries in a bounded in-process map with a TTL of about a second. That collapses each instance's Redis traffic for the key to one GET per second, at the price of staleness up to local TTL plus Redis TTL, and instances briefly disagreeing with each other.

Separate physical from logical expiry: give the Redis key a TTL longer than its freshness deadline and store that deadline inside the value. GET then always returns something; when the value is past its logical deadline, one caller wins a SET NX PX lock and rebuilds while everyone else returns the stale copy immediately.

They select which read keys the server bothers to track. OPTIN tracks nothing unless the client sends CLIENT CACHING YES immediately before a read; OPTOUT tracks everything except after CLIENT CACHING NO. Both shrink the server's tracking table and the invalidation traffic to only the keys the client actually caches locally.

Adopt it only where the read/write ratio is very high, the working set fits comfortably in process memory, and the data tolerates a millisecond-scale staleness window plus rare loss. Bound the risk with a local TTL, a hard size cap, flush-on-reconnect, per-class allowlists, and metrics on local hit ratio and invalidation volume — and start with one prefix, not the whole keyspace.