AEM + Elasticsearch on Kubernetes.

AEM consumes a stable search contract while the query service translates filters, pagination and result fields into Elasticsearch requests. This permits independent API releases without moving the AEM runtime into Kubernetes.

Scaling a stateless API does not create search-cluster capacity. Unbounded queries, retries and connection pools can multiply downstream load while apparently improving the API tier's resource utilization.

The query path runs from AEM through ingress or gateway routing to search API Pods and an existing Elasticsearch endpoint. A separate ingestion pipeline maps approved AEM content into the search model, applying stable document identifiers and explicit deletion handling.

Allowlist filters and sort options, enforce pagination limits, and constrain upstream timeouts and concurrency. Isolate search credentials in the query service and apply content-visibility rules so search results do not reveal restricted source content.

• Maintain a versioned response contract rather than exposing arbitrary Elasticsearch queries to callers.
• Make indexing operations idempotent and track content identity, updates and removals.
• Coordinate API replicas and connection budgets with the team operating the search endpoint.

Validate the candidate API against a compatible index before routing traffic to it. If the search schema changes, plan index population and reader compatibility with the search owner; a service rollout must not silently assume a new mapping already exists.

A fast search response can still contain stale or incomplete content. Track indexing lag, failed updates and deletion processing separately from API latency, timeout rate and dependency availability.

The extra service isolates query logic and credentials but adds routing, deployment and monitoring responsibilities. Caching may reduce repeated load, provided the key includes relevant filters and authorization scope and has a defensible freshness policy.

Continue with the complementary design in AEM Elasticsearch Integration: Search Queries, Facets and Content Freshness.

The intended outcome is an independently deployable query layer with clearer failure boundaries. It needs joint validation with the owners of AEM content and the search endpoint.

• Replay representative facets and pagination queries; measure API and downstream latency separately.
• Increase API replicas and verify total search connections and request concurrency remain bounded.
• Publish, update, unpublish and restrict source content; check index and response visibility.
• Make the search endpoint unavailable and verify bounded retries, useful error responses and recovery.

Search performance is a property of the whole query path and content lifecycle. Kubernetes can manage the API workload, but dependency capacity and result correctness remain explicit engineering concerns.

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

• Kubernetes: Deployments
• Kubernetes: Ingress and controller requirements
• Kubernetes: startup, readiness and liveness probes