Caching

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. ...

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. ...

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 ClientCDNDistributed edge locationsCache: static & edge-computed contentOrigin ServerSingle sourceof truthrequestcached responseon cache missorigin pull & cacheMost requests resolve at the edge; only misses/dynamic content reach the origin 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 ...

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 Cache-AsideAppCacheDBreadon miss: fetch + populateWrite-ThroughAppCacheDBwritesync writeWrite-BehindAppCacheDBwrite (fast ack)async flush (delayed) 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 ...