Summary
Search-heavy workloads cache popular queries and their result sets, absorbing the majority of search traffic from cache and reserving Elasticsearch or other search backends for uncached or freshness-sensitive queries.
Evidence
- ·{'E-commerce product search': 'the top 1000 most popular queries account for 60-70% of all search traffic'}
- ·Amazon and Etsy cache search results with 30-60 second TTLs for high-traffic queries
- ·Elasticsearch documentation recommends request caching and shard-level query cache for repeated identical queries
- ·Redis sorted sets can store ranked result lists with sub-millisecond access time
- ·Facebook's Memcache deployment was driven largely by caching search and feed results
Operational Context
- ·Cache key must include all query parameters (query string, filters, sort, page)partial keys cause correctness bugs
- ·TTL must be tuned to balance freshness with cache hit rate: 30-120 seconds is typical for product search
- ·Cache stampede on popular query expiry requires distributed locking or probabilistic early refresh
Tradeoffs
- ·Search result caching is only correct when eventual consistency is acceptable : cached results may be slightly stale
- ·Cache key cardinality can be very high with many facet combinations: unbounded cache memory growth
- ·Cache invalidation on index updates requires either short TTL or event-driven invalidation
Evidence grounding
Grounded, 5 supporting itemsSearch result caching is standard practice in e-commerce and content platforms. At high read volumes, even a 50% cache hit rate dramatically reduces search cluster load.