Caching

What Caching Solves

Caching stores hot data in faster storage (memory/edge) so systems can:

• reduce read latency,
• protect databases/services from repeated reads,
• increase throughput with the same backend capacity.

Caching is a performance optimization layer, not the source of truth.

Basic Read Path

1. Client requests data.
2. Cache lookup:
   • Hit -> return immediately.
   • Miss -> read from source, populate cache, return.
3. Eviction policy decides what remains when capacity is full.

Where Caching Appears

• Client/browser cache: static assets and API responses.
• CDN/edge cache: geo-distributed static delivery.
• Application cache: object/query/result caching near app tier.
• Database cache/buffer pool: page/block-level acceleration.
• DNS cache: domain resolution reuse.

What to Cache

Best candidates:

• read-heavy data,
• expensive-to-compute responses,
• slow remote lookups,
• data with acceptable staleness window.

Avoid caching:

• highly volatile or strictly real-time data without strong invalidation controls,
• low-reuse keys that pollute cache.

Eviction Policies

Policy	Best for	Trade-off
LRU	Temporal locality	May evict frequent older items
LFU	Stable popularity patterns	Extra frequency metadata
FIFO	Simplicity	Ignores access behavior
TTL-based	Freshness control	Sensitive to wrong TTL values
Random	Very low overhead	Unpredictable quality

Freshness and Invalidation

Caching correctness depends on invalidation strategy:

• TTL expiry,
• explicit delete/update on writes,
• versioned keys,
• event-driven invalidation.

How reads and writes coordinate with the cache is covered in Caching Strategies below.

Caching Strategies

Caching strategies define how data is read into cache, how writes reach cache and the source of truth, and how consistency, latency, and durability trade off.

Read Strategies

1) Cache-Aside (Lazy Loading)

Flow:

1. app reads cache,
2. on miss, app reads DB,
3. app populates cache.

Pros:

• simple and common,
• good control in application layer.

Cons:

• cache miss penalty hits request path,
• stale data risk unless invalidation is handled well.

2) Read-Through

Flow:

1. app asks cache,
2. cache fetches from DB on miss,
3. cache returns and stores value.

Pros:

• cleaner app code,
• central cache population logic.

Cons:

• tighter coupling to cache/data adapter,
• less app-level flexibility.

Write Strategies

1) Write-Through

Write to cache and DB in same path (usually sync).

Pros:

• cache + DB stay closely aligned,
• low data-loss risk.

Cons:

• higher write latency,
• DB write cost on every request.

2) Write-Back (Write-Behind)

Write to cache first; DB update happens asynchronously later.

Pros:

• very low write latency,
• absorbs bursty write traffic.

Cons:

• risk of data loss on cache failure before flush,
• more complex durability/replay pipeline.

3) Write-Around

Write directly to DB, skip cache on write.

Pros:

• avoids polluting cache with cold write data,
• simpler cache invalidation for write-heavy workloads.

Cons:

• next read likely misses cache and hits DB.
• Stale cache reads if the key is still present: the write updates only the DB, so you must invalidate or let the entry expire (TTL); otherwise clients can read an old cached value until then.

Trade-off Summary

Strategy	Read Latency	Write Latency	Consistency	Data Loss Risk
Cache-Aside	Fast on hit, miss penalty	N/A	Depends on invalidation	Low
Read-Through	Fast on hit, managed miss	N/A	Similar to cache-aside	Low
Write-Through	Good read freshness	Higher	Stronger cache/DB alignment	Low
Write-Back	Good after warm cache	Lowest	Eventual	Higher if flush fails
Write-Around	Miss after writes	Moderate	DB-first correctness	Low

Common Combinations

E-commerce style

• Cache-aside + write-through for inventory/price/order-adjacent reads.
• Goal: fast reads with stronger write correctness.

Social/media feed style

• Read-through + write-back for high-throughput timelines/interactions.
• Goal: absorb spikes and trade strict immediacy for throughput.

Operational Rules That Matter

• Define cache invalidation ownership clearly.
• Set TTLs by data volatility, not one global value.
• Protect DB from thundering herd (request coalescing, jittered TTL).
• Monitor hit ratio, eviction rate, stale-read incidents, flush lag.
• Add fallback behavior for cache outages.

Practical Selection Guide

• Prefer cache-aside as baseline for most services.
• Use write-through for correctness-sensitive writes.
• Use write-back only with strong durability controls.
• Use write-around when write volume is high and re-read probability is low.