Topology › Case Studies
Case Studies
Policy cards filed under Case Studies.
Case Studies
Myth-Busting: The Case for Putting Your Cache Key Before Your Load Balancer
LayerShared edge or reverse-proxy cache for HTTP responses, keyed on request attributes such as URL, headers, and cookies.
TtlShort TTLs for frequently changing content, longer TTLs for static assets; TTL should be set per content class rather than globally.
Hit rateHit rate depends on cache key granularity, request diversity, TTL length, and how many distinct keys the workload generates.
A common piece of architecture advice says to put the load balancer first and the cache behind it.
Case Studies
CDN Caching Isn't a Magic Switch: What Real Case Studies Teach Us
LayerEdge CDN cache for HTTP responses
TtlStatic assets: long (days to years) with versioning; dynamic content: short (seconds to minutes)
Hit rateAffected by content popularity, TTL, cache key design, origin headers, and request patterns
Content delivery networks are often pitched as a simple switch: turn on caching, and your site becomes faster and cheaper.
Case Studies
Stop Blaming the CDN: A Case-Study Guide to Cache Invalidation and Load Balancing
LayerReverse-proxy HTTP cache at the edge and origin, plus application-level key-value caching for computed fragments
TtlUse the shortest TTL that keeps origin load acceptable; seconds to minutes for frequently changing data, hours to days for stable assets, with stale-while-revalidate to absorb bursts
Hit rateAffected by request diversity, query-string and header normalization, cache key design, TTL length, and how much content is safely shareable across users
A common failure pattern in distributed systems is to treat the content delivery network as the source of every freshness problem.
Case Studies
Why Your Cache Hit Ratio Is a Lie (and How to Fix It)
LayerHTTP response caching at shared reverse proxies, CDN edge nodes, and application-level object caches such as Redis or Memcached
TtlShort TTLs for volatile or personalized data, longer TTLs for static assets, with stale-while-revalidate to mask origin latency
Hit rateKey design, cache key normalization, request distribution, object popularity, TTL, origin response headers, and cacheability of responses
Cache hit ratio is one of the most cited numbers in performance engineering, and one of the least trustworthy.
Case Studies
Caching Case Study: Fix Your Hit Rate Before Adding Load Balancers
LayerHTTP response caching at the reverse proxy or edge layer, keyed by request attributes such as URL, headers, and cookies.
TtlStart with short TTLs for dynamic content and longer TTLs for static assets; tune based on observed change frequency and tolerance for staleness.
Hit rateAffected by cache key design, request variety, TTL length, origin response cacheability, and how much content is personalized or frequently changing.
A team notices rising latency and origin load, so they add load balancers and more origin servers.
Case Studies
Why Your Cache Hit Rate Is a Lie (and How to Fix It)
LayerShared reverse-proxy or application-level cache sitting in front of an origin service, keyed by request attributes such as URL, headers, query string, and method.
TtlSet TTL from observed change frequency and tolerable staleness, not a single global default; hot, slow-changing objects can live longer, while volatile or personalized responses need short or zero TTL.
Hit rateDriven by key design, request diversity, cacheable response share, eviction pressure, working-set size relative to cache capacity, and how long entries survive before being replaced or invalidated.
A cache hit rate is one of the most quoted numbers in performance work, and one of the least trustworthy.
Case Studies
Stop Treating Your Cache Like Storage: Hard Lessons from Real Deployments
LayerHTTP response caching at the edge and shared object caching in memory, treated as a disposable copy of origin data rather than a durable store
TtlSet from measured change frequency per object class, not one global value; hot immutable assets can live long, while user-specific or rapidly mutating data should be short or uncacheable
Hit rateDominated by key cardinality, query-string and header variance, TTL length relative to object churn, and how much of the working set fits in the allocated memory or edge footprint
Most teams adopt a caching layer for one reason: the origin cannot absorb the traffic it is being asked to serve.
Case Studies
Forget Cache Hit Ratios: What Actually Worked When I Fixed a Product Catalog API
LayerApplication-level response caching for a product catalog API, layered in front of the primary datastore and keyed by normalized request parameters rather than raw URLs.
TtlShort-to-moderate time-to-live, on the order of minutes for volatile catalog slices and longer for stable reference data, always paired with explicit event-driven eviction so the time-to-live is a backstop rather than the primary freshness mechanism.
Hit rateHit rate is governed by key cardinality, how many distinct filter and sort combinations clients actually request, whether the cached payload is segmented into reusable fragments, and how much of the catalog changes between requests.
A product catalog API looks like an easy caching target until you actually run one.