Caching on IT Comparison

Cache Freshness vs Hit Rate: Correctness vs Efficiency

Sun, 06 Sep 2026 09:45:20 +0900

Overview

Cache freshness measures whether the data returned by a cache still matches the current state of its source of truth, while hit rate measures how often requests are answered directly from the cache instead of falling through to the origin. The two metrics pull in opposite directions: optimizing for freshness means shorter TTLs and more origin traffic, while optimizing for hit rate means longer TTLs and a higher chance of serving stale data. Tuning a cache well means choosing the right balance point for that specific data’s tolerance for staleness.

Local vs Shared Cache: Per-Instance Memory vs Centralized Cache Service

Sun, 06 Sep 2026 09:43:40 +0900

Overview

A local cache stores data in the memory of a single application process, giving the fastest possible reads but no visibility into what other instances hold. A shared cache lives in a separate service that every instance queries over the network, trading a bit of latency for one consistent view of cached data across the whole fleet. The choice shapes how you handle invalidation, scaling, and failure in a multi-instance deployment.

CDN vs Origin Server: Who Actually Serves the Request

Mon, 03 Aug 2026 06:23:28 +0900

Overview

A CDN is a distributed network of edge servers that caches and delivers content close to users, while the origin server is the single authoritative source where that content is created or stored. The distinction matters for latency, scalability, and resilience, since most requests should never need to reach the origin at all.

Comparison Diagram

Comparison Table

Aspect	CDN	Origin Server
Role in request path	Intercepts requests at the edge and serves cached content directly	Authoritative backend that generates or stores the original content
Geographic distribution	Many points of presence worldwide, close to end users	Typically one or a few fixed data center locations
Content served	Cached copies of static assets or cacheable API responses	Dynamically generated pages or master copies of files
Cache miss handling	Forwards uncached requests to the origin and stores the response per TTL	Processes every request that reaches it; has no caching layer of its own
Latency	Low, since content is served from the nearest edge node	Higher, since every request travels to one fixed location
Load on backend	Absorbs most traffic, shielding the origin from direct load	Only handles cache misses and non-cacheable requests
Resilience to outages	Can keep serving stale cached content if the origin goes down	Site is effectively unavailable for anything not already cached elsewhere
Scaling and cost	Scales via the CDN provider’s global network, billed per bandwidth/requests	Must be scaled and provisioned directly, billed for compute and hosting

Key Differences

CDN content lives on distributed edge nodes; the origin server is the single source of truth.
CDN caching cuts latency for users, but every cache miss still lands on the origin.
CDN edge caching gives resilience against origin outages by serving stale content.
Origin servers own dynamic content generation; CDNs only store what’s actually cacheable.

When to Use Each

CDN

Cache-Aside vs Write-Through vs Write-Behind: Caching Strategies Compared

Sun, 02 Aug 2026 23:52:10 +0900

Overview

Caching strategies differ mainly in who updates the cache and when. Cache-Aside leaves the application responsible for loading data into the cache on a miss and writing straight to the database, while write-through/write-behind caches push writes through the cache itself — synchronously for durability or asynchronously for speed. The choice shapes consistency guarantees, crash-safety, and how much write latency the app absorbs.

Comparison Diagram

Comparison Table

Aspect	Cache-Aside	Write-Through / Write-Behind
Read path	App checks the cache first; on a miss, it reads from the DB itself and populates the cache	Cache is always kept current on writes, so reads simply hit the cache without app-managed fallback logic
Write path	App writes directly to the DB; the cache entry is invalidated or left stale until the next read	App writes only to the cache; the cache layer propagates the write to the DB itself
Write latency perceived by app	Only DB write latency, since the cache isn’t touched on write	Write-Through waits for both cache and DB commit; Write-Behind returns after the cache write only
Consistency between cache and DB	Brief staleness window possible between invalidation and the next read	Write-Through stays consistent immediately; Write-Behind lags until the queued flush completes
Data loss risk on crash	None — the DB is always the write target, so a cache crash loses nothing	Write-Through has no loss; Write-Behind can lose unflushed writes if the cache crashes before flush
Implementation complexity	App owns miss handling and invalidation logic explicitly	Cache layer owns persistence logic; Write-Behind adds a queue/flush scheduler
Typical use case	Read-heavy workloads with unpredictable key access, e.g. Redis in front of a relational DB	Write-Through suits systems needing instant durability; Write-Behind suits high write-throughput systems tolerant of brief loss, e.g. metrics buffers

Key Differences

Cache-Aside puts the application in charge of both fetch-on-miss and invalidation, while write-through/write-behind push that responsibility into the cache layer itself
Only Write-Behind delivers real write latency savings by acknowledging before the DB commit completes
Write-Through guarantees immediate durability at write time, while Write-Behind trades some of that durability for throughput
Cache-Aside is the only strategy where a cache outage never risks data loss, since writes never pass through it

When to Use Each

Cache-Aside