caching-strategy

Identify read-heavy data with tolerable staleness, then apply the cache-aside pattern: check Redis first, query the database on miss, and store results with a TTL. Set TTLs by data type, such as 5 minutes for user profiles and 1 hour for product catalogs.

TTL depends on freshness requirements: 30 seconds for search results, 5 minutes for user profiles, 1 hour for product catalogs, and 24 hours for session tokens. Avoid infinite TTLs since they guarantee eventually stale data.

Cache-aside loads data into cache only on demand, keeping memory efficient but making first requests slow. Write-through updates cache synchronously on every write, keeping cache fresh at the cost of higher write latency.

Use a distributed lock so only one request rebuilds the cache while others wait and retry. In Redis, acquire a lock with SET NX EX before querying the database, then release it after repopulating the key.

Avoid caching data requiring real-time accuracy like financial transactions, high-write-frequency data like inventory counts, and sensitive data like passwords or credit cards. High-write workloads above 50% writes may make caching counterproductive.

A hit rate below 70% usually means you are caching the wrong data or TTLs are too short. Focus on hot data where 20% of keys serve 80% of requests, and lengthen TTLs for frequently accessed keys.