How do we cache personalized pages without leaking data?

Separate truly personalized content from cacheable shells. Cache the shell (HTML or JSON) at the edge and hydrate user-specific data via client-side or server-side includes with strict `Vary` rules. Use `Vary: Cookie` only when necessary and prefer signed, scoped tokens for per-user fragments in Redis with short TTLs.

Should we use Redis or Memcached?

Redis for most cases: richer data types, Lua/ACLs, Streams, and easier clustering. Memcached is fine for simple key/value with very low latency and huge object counts. We usually standardize on Redis 6+ with cluster mode, latency monitoring, and eviction policy `allkeys-lru` for fragment caches.

Is write-through better than cache-aside?

For reads, cache-aside is simplest and keeps cache failure from taking down writes. For hot, frequently updated resources (e.g., inventory counts), write-through or write-behind can work—paired with short TTLs and idempotent updates. Measure miss penalty and staleness tolerance before choosing.

How do we prevent cache poisoning at the edge?

Whitelist which headers/params affect cache keys. Strip untrusted headers, ignore query params by default, and sign any keys that depend on user input. Use WAF rules and content validation for HTML/JS. Enable response size limits to avoid oversized cache entries.

What’s a good hit ratio target?

Depends on your mix. Static assets should be 95%+. Semi-static pages (home, category, PDP) 70–90%. API fragments 60–85%. Track hit ratio alongside miss penalty; a high CHR with brutal misses still feels bad to users.

Performance-optimization · Nov 28, 2025 · 9 minute read

The Cache Stack That Halved p95 TTFB and Cut Our Cloud Bill by 38%

Multi‑tier caching that speeds up user experiences and takes pressure off your infra bill—without waking PagerDuty.

Back to all posts

The Cache Stack That Halved p95 TTFB and Cut Our Cloud Bill by 38%

Key takeaways

Implementation checklist