Opensearch Personalize Caching Strategies

Marketplace-Research OpenSearch + Personalize Caching Best Practices

A reference distillation of caching strategies for two-sided marketplaces running AWS OpenSearch (search) and AWS Personalize (recommendations behind a microservice). Contains 52 rules across 9 categories, ordered by cascade effect — from the upstream decision of whether to cache, through key design, personalisation boundary, strategy selection, TTL design, stampede protection, observability, and the lower-cascade categories of negative caching and tier composition. Each rule explains the WHY (the cost, latency, or correctness mechanism), shows incorrect-vs-correct code (TypeScript/Node for the microservice layer, Python for batch and analytics, OpenSearch JSON for OS-specific queries, YAML for CDN/Kubernetes), and cites the canonical source — AWS Personalize/OpenSearch/ElastiCache documentation, the XFetch paper (Vattani et al. VLDB 2015), RFC 5861 (stale-while-revalidate), and the engineering blogs of cache infrastructure teams (Netflix EVCache, Pinterest Cachelib, Twitter Twemcache, Cloudflare).

This is the complement to opensearch-function-scoring-algorithms — that skill answers "what should the ranking compute?", this skill answers "how do you scale it to production traffic without burning down OpenSearch or Personalize?"

When to Apply

Reach for this skill when:

• Adding caching to a search or recommendation surface for the first time — start with decide-cache-roi-calculation and decide-hot-key-distribution
• A homepage or category page renders 5+ recommenders and Personalize bills are growing faster than traffic — decide-amplification-multiplier, pers-recommender-fan-out-coalescing, pers-cohort-precomputation
• Cache hit rate is suspiciously low (under 30-40%) and you don't know why — key-canonicalize-query, key-strip-volatile-params, key-bucket-numerical-ranges, obs-key-cardinality-tracking
• Personalize is throttling (HTTP 429) during traffic spikes — decide-personalize-quota-budget, neg-cache-throttled-personalize, stamp-circuit-breaker-on-origin-error
• p99 spikes at TTL boundaries — stamp-coalesce-concurrent-misses, stamp-probabilistic-early-expiration, stamp-serve-stale-on-rebuild, ttl-soft-and-hard, ttl-jitter-to-prevent-thundering
• Recommendations stay stale after a model retrain — key-version-the-model, ttl-personalize-solution-version, strat-async-warm-up
• A read-after-write surface shows stale data (user favourites, saved searches) — strat-write-through-mutations, ttl-event-driven-invalidation
• Cache decisions need to be defensible to finance — decide-cache-roi-calculation, obs-cost-attribution, obs-cache-simulation-from-logs
• Anonymous and logged-in traffic mix on the same routes — pers-anonymous-vs-logged-split, tier-cdn-for-anonymous
• Cache is at memory pressure and you need to know whether to upsize, shorten TTL, or change strategy — decide-hot-key-distribution, tier-l2-elasticache-redis, obs-cache-simulation-from-logs
• OpenSearch CPU is high on common queries — tier-opensearch-request-cache, tier-opensearch-filter-context, neg-cache-empty-results
• A traffic spike from a viral link or crawler is hammering the origin — neg-bloom-filter-against-misses, neg-cache-empty-results, stamp-circuit-breaker-on-origin-error

The rules apply to any AWS-based marketplace with OpenSearch and Personalize fronted by an application microservice, regardless of vertical — accommodation, food delivery, fashion, services, jobs, secondhand goods, real estate. Triggers include "cache hit rate", "cache miss storm", "Personalize throttling", "Personalize cost", "multi-recommender page", "cohort caching", "single-flight", "stale-while-revalidate", "XFetch", "OpenSearch slow queries", "ElastiCache sizing", "CloudFront search caching", "Bloom filter cache penetration", and "thundering herd".

The Caching Pipeline

Categories are derived from the request-time caching pipeline. Earlier stages cascade: a wrong "should we cache?" decision wastes everything below; un-canonicalised keys cap hit rate at a fraction of the achievable ceiling; without observability you can't tell whether any of the rules helped.

Request → [1] Decide → [2] Key construction → [3] Personalisation boundary
        → [4] Strategy (read/write path) → [5] TTL/freshness → [6] Stampede protection
        → [8] Negative/defensive → [9] Tier composition (L1/L2/CDN/OS-internal) → Response
                                                ↑
                                [7] Observability (meta-layer applied to all stages:
                                    hit rate by key class, latency-with-and-without,
                                    cost-per-1k, cardinality, staleness, log-replay)

Rule Categories by Priority

Quick Reference

1. Decision & Cost Calculus (CRITICAL)

• decide-cache-roi-calculation — Compute Cache ROI Before Adding the Cache
• decide-cardinality-floor — Skip Caching When Traffic Distribution is Flat
• decide-personalize-quota-budget — Model Personalize TPS Budget Before Choosing a Cache Strategy
• decide-latency-budget — Cache Only When Origin p99 Exceeds the Latency Budget
• decide-amplification-multiplier — Account for Multi-Recommender Page Amplification
• decide-hot-key-distribution — Profile Traffic Distribution Before Sizing the Cache
• decide-search-vs-personalize-asymmetry — Cache Candidate Sets for Search, Full Payloads for Personalize

2. Cache Key Design (CRITICAL)

• key-canonicalize-query — Canonicalise Queries Before Hashing
• key-segment-not-user — Key Recommenders by Cohort When Users Outnumber Cohorts
• key-version-the-model — Include the Personalize Solution Version in the Cache Key
• key-locale-currency-explicit — Make Locale, Currency, and Timezone Explicit in the Key
• key-strip-volatile-params — Strip Volatile and Tracking Params Before Hashing
• key-bucket-numerical-ranges — Bucket Continuous Filters Before Hashing
• key-stable-hash-algorithm — Use SHA-256 over MD5 for High-Cardinality Keys

3. Personalisation Boundary (HIGH)

• pers-cohort-precomputation — Precompute Recommendations Per Cohort Offline
• pers-anonymous-vs-logged-split — Route Anonymous Traffic to Global Cache, Logged-in to Cohort Cache
• pers-cold-start-cache-priority — Serve Cold-Start Users From Popularity Cache, Skip Personalize
• pers-recommender-fan-out-coalescing — Coalesce Multi-Recommender Fan-Out Into Batched Calls
• pers-shared-candidates-private-ranking — Cache Retrieval Candidates Globally, Re-Rank Per-User From Cache
• pers-session-vector-write-through — Maintain Session Vectors in Cache with Write-Through on Every Event

4. Strategies & Write Paths (HIGH)

• strat-cache-aside-default — Use Cache-Aside as the Default Strategy for Read-Heavy Paths
• strat-refresh-ahead-hot-keys — Use Refresh-Ahead Only for the Top 1% of Hot Keys
• strat-write-through-mutations — Use Write-Through When User Mutations Are Immediately Re-Read
• strat-precompute-batch — Precompute the Popular Fraction with Batch Jobs
• strat-tiered-promotion — Promote to L1 In-Process Cache on L2 Hit
• strat-async-warm-up — Async Warm-Up After Deploy, Restart, or Model Retrain

5. TTL & Freshness (HIGH)

• ttl-by-content-volatility — Set TTL From Content Volatility, Not Engineering Convenience
• ttl-soft-and-hard — Separate Soft TTL (Async Refresh) from Hard TTL (Sync Miss)
• ttl-jitter-to-prevent-thundering — Add Random Jitter to TTL to Prevent Synchronized Expiry
• ttl-personalize-solution-version — Pin TTL to Personalize Solution Version, Not Wall Clock
• ttl-event-driven-invalidation — Pair TTL with Event-Driven Invalidation for Critical Freshness
• ttl-bound-by-staleness-tolerance — Bound TTL by Product Staleness Tolerance, Not the Default