PrepZone Logo
PrepZone
Start Free Trial

Cache Fundamentals

What caching buys you, where it sits in the stack, and when it hurts more than helps.

Intermediate9 min read

Read these first

Why this matters

  • VaultCommerce product pages dropped from 180 ms to 12 ms p95 when hot SKUs moved behind Redis — without caching, Postgres replicas saturated during peak hours.
  • Misapplied caches cause stale prices, phantom inventory, and debugging nightmares.
  • Every backend interview touches where caching sits and what consistency you sacrifice.
App
RedisCache
PostgresSource of truth
Redis
App checks cache first. On miss, reads DB and populates cache.

What caching buys you

Cache benefits

  • Lower latency — memory reads in microseconds vs milliseconds on disk.
  • Reduced load — fewer queries hit the database during traffic spikes.
  • Cost efficiency — scale reads with RAM instead of larger database instances.
  • Absorbed spikes — flash sales hit cache first; database sees smoothed traffic.
Java
Without cache:
  Browser → API → Postgres replica → 45 ms query → response

With cache:
  Browser → API → Redis hit → 1.2 ms → response
  (miss path: API → Postgres → populate Redis → response)

VaultCommerce targets 90%+ cache hit ratio on product detail keys during normal traffic.

Where caches live in the stack

LayerExampleVaultCommerce use
BrowserHTTP Cache-ControlStatic assets, CDN
CDN edgeCloudFrontProduct images, JS bundles
ApplicationIn-process CaffeineFeature flags, category tree
DistributedRedis clusterSessions, carts, product JSON
DatabasePostgres shared_buffersHot index pages

  • Browser

    ExampleHTTP Cache-Control
    VaultCommerce useStatic assets, CDN

  • CDN edge

    ExampleCloudFront
    VaultCommerce useProduct images, JS bundles

  • Application

    ExampleIn-process Caffeine
    VaultCommerce useFeature flags, category tree

  • Distributed

    ExampleRedis cluster
    VaultCommerce useSessions, carts, product JSON

  • Database

    ExamplePostgres shared_buffers
    VaultCommerce useHot index pages

Each layer has different TTL, invalidation, and consistency semantics. A CDN cache miss still benefits from Redis; Redis miss still hits Postgres.

When caching hurts

Cache anti-patterns

  • Low hit ratio — caching rarely-read keys wastes memory and adds code paths.
  • Large objects — serialising 2 MB product blobs per key exhausts Redis memory.
  • Write-heavy data — inventory counts invalidate faster than they cache.
  • Correctness-critical paths — payment balances should not rely on stale cache alone.

VaultCommerce caches product descriptions aggressively but reads available quantity from Postgres with a short TTL only on browse pages — checkout always hits the authoritative row lock.

Measuring cache health

Track hit ratio, eviction rate, memory usage, and p99 latency:

Java
INFO stats
# keyspace_hits:4829103
# keyspace_misses:412087
# hit ratio ≈ 92.1%

Alert when hit ratio drops below 80% during steady traffic — often a sign of key churn, TTL misconfiguration, or a deployment that changed key naming.

Quick recall

Everything you need if you only revisit this box.

  1. Caches trade freshness for speed — know your consistency budget per key.
  2. VaultCommerce layers CDN, in-process, and Redis caches before Postgres.
  3. Cache read-heavy, relatively stable data with high reuse — not every column.
  4. Monitor hit ratio, memory, and eviction — low hits mean the cache isn't earning its keep.
  5. Authoritative data stays in the database; cache is a performance layer, not truth.

Test yourself

Answer these before moving on — recall is what makes it stick.