Search Heavy

read heavy

Summary

Full-text search, faceted filtering, and ranked result retrieval at high read throughput. Index refresh latency (1-second default in Elasticsearch) means freshness is near-real-time but not instantaneous. Read scaling through shard replicas is the primary lever.

Example Systems

·E-commerce product search
·Job board search (LinkedIn, Indeed)
·Document search (Confluence, Notion)
·Code search (GitHub, Sourcegraph)
·Log search (Kibana)

Characteristics

CategorySEARCH

Read / write patternread heavy

Latency requirementlow

Consistency requirementeventual

Durability requiredNo

Ordering requiredNo

Capacity

Typical RPS20,000

Peak RPS100,000

Typical data volume2,000 GB

Growth rate20-200 GB/month; dominated by document index size and replica overhead

Seasonal spikes: Shopping season, news events, and promotional emails drive 5x search spikes (5× multiplier)

Access Patterns

point lookuprange scanpoint lookup

Recommended Patterns

cache asidecqrsmaterialized viewread replica

Patterns to Avoid

two phase commitsharding

Basis

Search workload characteristics are well-documented through Elasticsearch production guides and LinkedIn engineering posts

Related Architecture Knowledge

Outbound: this entity affects

Benefits FromPattern

cache aside

Grounded

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.

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

Full relationship →

Benefits FromPattern

vector similarity search

Draft · unverified

Search-heavy workloads benefit from vector similarity search when queries require semantic matching beyond exact keyword lookup, enabling discovery of conceptually related content.

Full relationship →

Used In Architecture Scenarios

Search-Heavy Content Platformhigh

Search-Heavy Application

A content platform architecture centered on Elasticsearch for full-text search, faceted navigation, and ranked results, with PostgreSQL as the transactional source of truth and Redis for session management and hot content caching. WAL-based CDC maintains index freshness by streaming PostgreSQL changes into Elasticsearch asynchronously. The core tension is between search index freshness, query performance, and index maintenance cost under high write volume.