Caching Patterns

Cache-aside, read-through, write-through, and write-behind — with VaultCommerce cart examples.

Intermediate11 min read

Read these first

Cache Fundamentals

Why this matters

VaultCommerce's cart, catalog, and session layers use different patterns because they have different freshness and durability needs.
Picking the wrong pattern causes double writes, lost updates, or caches that never invalidate.
Interviews ask you to diagram cache-aside and defend when write-through is worth the latency tax.

Cache-aside (lazy loading)

The application owns cache logic — check cache, on miss load DB, populate cache.

App

RedisCache

PostgresSource of truth

Redis

App checks cache first. On miss, reads DB and populates cache.

Java

public Product getProduct(String sku) {
    String key = "product:" + sku;
    Product cached = redis.get(key);
    if (cached != null) return cached;

    Product product = productRepo.findBySku(sku);
    if (product != null) {
        redis.setex(key, Duration.ofMinutes(10), product);
    }
    return product;
}

VaultCommerce uses cache-aside for product pages — simple, debuggable, and the database remains source of truth. Invalidation happens on catalog update events.

Read-through and write-through

Aspect	Read-through	Write-through
Who loads on miss	Cache library	Application
Write path	App writes DB only	App writes cache; cache writes DB
Consistency	Cache always populated on read	Cache and DB updated together
VaultCommerce	Not used — prefer explicit control	Session tokens (short TTL)

Who loads on miss
Read-throughCache library
Write-throughApplication
Write path
Read-throughApp writes DB only
Write-throughApp writes cache; cache writes DB
Consistency
Read-throughCache always populated on read
Write-throughCache and DB updated together
VaultCommerce
Read-throughNot used — prefer explicit control
Write-throughSession tokens (short TTL)

Write-through adds write latency because every update hits cache and database synchronously. VaultCommerce uses it only for session tokens where stale reads are unacceptable and objects are small.

Write-behind (write-back)

Writes go to cache first; the cache asynchronously flushes to the database in batches.

Java

App → Redis (immediate ack)
       ↓ async batch (every 500ms)
     Postgres

High write throughput, risk of data loss if the cache node dies before flush. VaultCommerce uses write-behind only for analytics counters — never for orders or inventory.

Pattern selection guide

Cache-aside — default for read-heavy, eventually consistent data.
Read-through — when you want transparent caching in a client library.
Write-through — small objects needing tight cache-DB consistency.
Write-behind — high-volume, loss-tolerant metrics and counters.

VaultCommerce pattern map

Data	Pattern	TTL / invalidation
Product JSON	Cache-aside	10 min TTL + CDC invalidation
Shopping cart	Cache-aside	7-day TTL, refresh on write
Session token	Write-through	30 min sliding TTL
Page view counter	Write-behind	Flush every 1s to Cassandra
Category tree	Read-through (in-process)	Refresh hourly

Product JSON
PatternCache-aside
TTL / invalidation10 min TTL + CDC invalidation
Shopping cart
PatternCache-aside
TTL / invalidation7-day TTL, refresh on write
Session token
PatternWrite-through
TTL / invalidation30 min sliding TTL
Page view counter
PatternWrite-behind
TTL / invalidationFlush every 1s to Cassandra
Category tree
PatternRead-through (in-process)
TTL / invalidationRefresh hourly

Invalidation strategies

Java

invalidation_options:
  ttl_only: simple, accepts temporary staleness
  event_driven: catalog service publishes ProductUpdated → delete redis key
  versioned_keys: product:v2:SKU123 — flip version on deploy
  write_invalidate: update DB then DEL cache key in same request

VaultCommerce prefers event-driven invalidation for catalog changes — TTL alone would show wrong prices for up to ten minutes after a sale starts.

Quick recall

Everything you need if you only revisit this box.

Cache-aside: app checks cache, loads DB on miss, populates cache — the default pattern.
Write-through keeps cache and DB in sync on every write at the cost of latency.
Write-behind batches writes — fast but lossy; never for financial data.
VaultCommerce: cache-aside for products, write-through for sessions, write-behind for metrics.
Pair TTL with event-driven invalidation for data that changes on business events.

Test yourself

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