Caching & Redis

I use a cache when repeated reads or calculations create measurable latency or load and the result can tolerate a defined freshness window. It trades memory and operational complexity for less origin work. I still consider query optimization and indexes first, because caching can hide an expensive underlying path until a cold start or outage exposes it. I also define invalidation, capacity limits and fallback behavior before judging the change by its warm-cache latency.

I use IMemoryCache for in-process values where independent instance copies are acceptable. It avoids network and serialization costs but disappears on restart and is not shared. IDistributedCache represents an external byte store, commonly Redis, so instances can access the same cached value. That introduces serialization, network failures and deployment compatibility concerns. Neither abstraction makes cached data authoritative or guarantees it can never disappear. I design misses and rebuilds as normal behavior in both cases.

I implement cache-aside by checking the cache, loading the authoritative source on a miss, and storing a copy with a bounded lifetime. The application owns that flow and invalidates related entries after a committed write. It is a good fit for read-heavy data with tolerated staleness. However, concurrent misses can overload the source, and readers can repopulate old values around a write, so I also consider single-flight loading and a deliberate consistency policy.

I use HybridCache to simplify typed caching with local memory and an optional distributed second level. It handles serialization, supports tags and coordinates concurrent loads for the same key within one HybridCache instance. That removes repetitive application code, but it is not a distributed lock across servers. Other instances can still load independently and retain local values until expiration. I therefore choose local and distributed lifetimes according to freshness requirements and do not use tags as a correctness boundary.

I combine a bounded TTL with explicit invalidation after the source transaction commits. Depending on the data, I use keys, tags, durable invalidation events or versioned key generations. I define the tolerated stale window rather than claiming eviction provides strong consistency. A reader can still fill an old value after a concurrent write, and another instance can hold a local copy. Correctness-critical decisions bypass stale copies or use an authoritative version check and atomic source operation.

I call it a stampede when many requests miss the same popular entry and all recompute it together. I use single-flight loading to share that work, with refresh-ahead or bounded stale-while-revalidate where the business permits it. HybridCache coordinates loads locally, so I still account for multiple instances. TTL jitter helps distribute different keys' expirations but does not alone prevent a burst against one missing key. I also bound origin concurrency to survive cold starts.

I distinguish penetration, where repeated requests target nonexistent keys, from an avalanche, where many entries expire together or the cache becomes unavailable. For penetration I validate inputs, apply rate limits and optionally cache a genuine not-found result briefly. For avalanches I spread expiration times, warm gradually and limit fallback concurrency. I never negative-cache a timeout as if the item did not exist, and I bound cache capacity so arbitrary input cannot create unlimited negative entries.

I use read-through to mean a caching layer that loads the source transparently on a miss. Write-through routes writes through a layer that updates the authoritative store and cache before acknowledging. Write-behind acknowledges buffered changes before persisting them asynchronously. I clarify these definitions because terminology varies between products. None automatically makes Redis and SQL one transaction. Write-through needs a partial-failure policy, and write-behind requires durable buffering, recovery and an explicit tolerance for delayed persistence.

I use output caching to store complete responses on the server under application policies, including expiration, variation and tags. HTTP caching uses protocol headers to control browser and shared-cache reuse. An ETag supports conditional validation and a 304 response when the authorized representation is unchanged. I keep public and personalized content separate, preserve the output-cache defaults around authenticated requests, and make every representation dimension part of the variation policy before enabling shared response caching.

I do not read no-cache as a prohibition on storage. It allows storage but requires validation before reuse. No-store tells caches not to store the response, while private prevents shared caches from storing it but can still permit a browser cache. I choose the directive according to the sensitivity and reuse requirements, together with authorization and secure transport. These headers are cache instructions; they do not make exposed data confidential or erase copies already obtained by a client.

I derive tenant identity from an authenticated, authorized context and include it in every tenant-specific key. I add user identity when content is personalized, plus relevant language, currency, filter and schema-version dimensions. Values are normalized and bounded so attacker-controlled input cannot create collisions or unbounded key growth. The source query remains tenant-scoped, and authorization happens before serving cached data. I test cross-tenant access explicitly because a perfectly functioning cache can otherwise distribute another tenant's information very efficiently.

I do not use a stale copy as the authority for stock reservation, balance debiting or a sensitive access decision without an explicit revocation model. Those decisions need an atomic operation or current validation at the source. A cached stock display can still be useful if checkout revalidates availability. I also avoid caching passwords, payment security codes or secrets in public responses. Personal data needs a justified purpose, correct partitioning, limited retention and protection at rest and in transit.

I treat a distributed lock as a lease with a deadline. A paused process or network interruption can exceed that deadline, allowing another worker to acquire the lock while the original later resumes. A unique token and atomic compare-and-delete make release safer, but they do not stop stale writes. For correctness I use a monotonic fencing token that the protected resource enforces, or rely on database concurrency and constraints. Renewal improves availability but does not eliminate every failure window.

I use Redis data structures for counters, rate limiting, session storage, sets and sorted-set leaderboards. Pub/Sub supports transient broadcast, while Streams can retain records and support consumer groups under configured retention. I choose the structure around the required delivery and recovery semantics. An individual atomic command does not make a multi-command workflow atomic, so related updates may require a transaction or script. I also evaluate persistence, replication and eviction settings before storing anything that cannot simply be rebuilt.

I compare end-to-end latency and origin load before and after caching, alongside hit ratio, evictions, payload sizes and cache errors. I separate local and distributed hits because their costs differ. Then I exercise cold starts, unavailable Redis and failed invalidation. Fallback must have timeouts and bounded database concurrency; otherwise a cache outage can become a database outage. I define whether each endpoint may serve bounded stale data, degrade its response or fail safely under those conditions.