Caching and Connection Management Questions

Requirements & constraints:

• Read-heavy product catalog, updates a few times/day (low write QPS), low read latency, eventual strong-ish consistency acceptable for catalog reads (price/availability less tolerant).
• Use Redis as distributed cache, origin DB as source of truth.

High-level approach:

• Use cache-aside as primary pattern: reads check Redis → on miss, fetch from DB, populate cache with metadata (version/ETag) and appropriate TTL.
• For updates (few/day), combine short TTL + pub/sub invalidation for near-immediate consistency.

Cache invalidation options (trade-offs):

• Time-based TTL
  • Pros: simple, resilient to missed invalidations.
  • Cons: stale data window = TTL; if long TTL reduces DB load but increases staleness.
  • Use: conservative baseline (e.g., 5–15 min) for non-critical fields.
• Write-through
  • Pros: cache always updated on writes.
  • Cons: adds write latency and complexity; redundant for rare writes.
  • Use: only if writes must reflect instantly and write latency acceptable.
• Write-back
  • Pros: fast writes to cache, deferred DB persistence.
  • Cons: data loss risk on failure; unsuitable for catalog where DB is source of truth.
• Pub/Sub invalidation
  • Pros: immediate invalidation/refresh across cache nodes; good for low-frequency updates.
  • Cons: complexity and potential message loss; combine with TTL as safety net.
  • Use: on each catalog update publish an invalidation message (key or version) to Redis Pub/Sub or messaging system (Kafka).

Consistency guarantees to accept:

• Eventual consistency for most catalog attributes (description, images) — acceptable short staleness (seconds–minutes).
• Stronger consistency for price/stock: use write-through or immediate cache invalidation + short TTL and read-through on misses. Optionally mark critical fields with zero/very short TTL and force DB read if update in last X seconds.

Operational practices:

• Use versioned keys or ETag metadata to avoid race conditions on concurrent updates.
• Implement "request coalescing" / single-flight to avoid thundering herd on cache miss.
• Fallback: on pub/sub failure, TTL ensures eventual recovery.
• Monitor cache hit rate, invalidation latency, and stale-read alerts. Autoscale Redis and use replication for HA.

Recommendation:

• Cache-aside + pub/sub invalidation for updates + conservative TTLs. Use write-through only for critical fields if absolute freshness required. This balances low read latency, low write complexity, and acceptable consistency for a read-heavy, rarely-updated catalog.