AEM Elasticsearch Integration: Search Queries, Facets and Content Freshness.

Define representative queries, exact filters, sorting and empty states before implementing the integration. External search is a deliberate product and architecture choice, not evidence that every JCR query requires replacement.

A result list can appear plausible while its counts, publication visibility or language handling are wrong. Capture expected behavior for combinations of filters, not only a single successful keyword search.

A Java service translates bounded search inputs into queries and maps results into a stable response. Define how published content reaches the index, how deletions propagate and what freshness means; no specific indexing implementation is claimed.

Use relevance-bearing queries for text matching and filter context for exact conditions where scoring is not required. Decide whether a selected filter should affect facet counts: filtering the query and applying a post-filter have different effects on aggregations.

• Bound page sizes and validate sort and filter fields.
• Specify behavior for missing documents and stale links.
• Set dependency timeouts and a deliberate user-facing failure response.

Define whether counts describe the current result set or alternative selections. This decision drives query construction and prevents frontend and backend implementations from silently interpreting filters differently.

Search-specific capabilities add another representation of content to maintain. Publishing and indexing are not automatically atomic, so the design needs a freshness policy and a way to diagnose divergence.

To isolate the search integration from presentation, use an explicit OSGi service contract.

Build a representative content set with expected results rather than claiming query optimization from isolated timings.

• Check keyword, empty-query and multi-filter cases with expected counts.
• Publish, update and remove a document and inspect visibility transitions.
• Test timeout, invalid-input and zero-result behavior independently.

The useful engineering artifact is a set of reproducible search expectations. Cluster sizing and performance gains need separate evidence and are not asserted in this case study.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• Elastic: query and filter context
• Elastic: filtering search results and aggregations