Separating Query and Indexing Responsibilities in Elasticsearch

An anonymous e-commerce search engagement using specialized nodes, storage tiers and query routing, with a parallel-cluster migration approach.

Separate catalog queries from the work that maintains the index

An e-commerce marketplace needed to serve product searches while continuing to update its catalog. Its Elasticsearch deployment used uniform nodes for several responsibilities. The redesign addressed query coordination, storage placement and indexing work rather than treating a larger set of identical nodes as the only option.

Ampity designed a tiered, self-managed Elasticsearch architecture with specialized node responsibilities and query-routing changes. The migration approach placed a new cluster alongside the existing one and shifted search traffic gradually. The customer remains anonymous. This case describes that engineering scope without publishing a latency, availability, cost or revenue benchmark.

Choose an operating responsibility along with the deployment model

The team considered a managed search service, another search technology and a self-managed redesign. The selected approach retained Elasticsearch while giving the team control over node specialization and routing. That choice also left the team responsible for the cluster's configuration, capacity, upgrades and incident handling.

The existing requirements included continuing catalog updates, preserving useful search results and moving consumers incrementally. Team familiarity and the work needed to change search technology shaped the alternatives. The recorded selection does not make self-management cheaper or more suitable for another organization. A new decision needs the actual workload, supported versions and operating capacity.

A managed option can change who performs infrastructure work without removing the application's search contract. Replacing the engine adds a different compatibility task. Before choosing either, identify the queries, updates and failure behavior that the product must preserve, then assign ownership of the work each option leaves behind.

Route a query against its intended data scope

The design assigned query coordination to dedicated nodes and differentiated hot, warm and cold storage responsibilities. It also used index aliases and routing strategies to limit the data searched for relevant query patterns. These are the recorded design choices, not a published shard layout or a reusable configuration file.

For a comparable review, begin with the meaning of a query. A product lookup, a category browse and a historical query may require different document populations. A route that reaches fewer shards is useful only if it still searches the required population and preserves the accepted result. An empty response can indicate a valid absence or a route that omitted the relevant data.

Keep storage placement and query eligibility distinct. A document becoming older does not by itself mean a customer no longer needs to find it. Record which data each required query must reach before changing placement or routing. This case does not prescribe an aging schedule, installed lifecycle policy or per-product replication mechanism.

Include the uncached path in the search contract

Caching formed part of the redesign alongside node specialization. A reusable review should ask which result may be reused, how changes become visible and what load reaches the underlying search path when a cached result is absent.

Amazon's caching guidance discusses stale values and downstream load when caches are cold or unavailable. Apply that as a general failure question, not as evidence of this engagement's cache configuration. A fast cached response does not establish that an inventory change is visible or that the uncached path can handle the required requests.

For a later comparison, retain the query, selected data scope, response and relevant catalog revision together. Keep cache state explicit instead of comparing one path with populated caches against another without them. No cache size, expiry rule, hit ratio or cache-failure test is asserted here.

Move readers without losing the changes made during coexistence

The migration introduced the new cluster beside the previous one, transferred data and expanded the search-traffic shift incrementally. Keeping both clusters available gave the project a transition boundary, but returning a reader to the previous endpoint still depends on what data that endpoint contains.

For a comparable transition, identify how new products, changed attributes and removals reach each cluster during coexistence. A baseline copy can become stale while indexing continues. The release owner needs an accepted comparison cut and a policy for changes that have reached only the new path before treating the previous cluster as a return option.

Amazon's rollback-safety discussion explains why individually working versions can still disagree during a transition. Here the practical question is whether the consumer, query behavior and retained data remain compatible when direction changes. Keeping an endpoint does not supply missing updates or undo decisions already made from a search result.

Review an existing query before changing its route

Begin with authorized read-only query definitions, permitted catalog records and existing migration observations. The worksheet below is proposed for a comparable review. It is not an execution record from this engagement.

Any later rehearsal requires a separately approved isolated cluster or equivalent test target, synthetic or approved sanitized catalog data, scoped identities and non-delivering consumers. Bound query load, indexing volume, runtime and spend. Stop if a test reaches production indexing, exposes unauthorized data or produces an unexplained population difference. Do not replay customer searches or change a live alias merely to fill a missing worksheet field.

Next action: agree what a search result must preserve

This approach is worth evaluating when query serving and index maintenance need different resources or ownership, and the team can operate the resulting responsibilities. It is less suitable as a default when a simpler supported arrangement meets the product contract or the organization cannot own the self-managed cluster.

Choose a permitted product query and name its required population, freshness and result behavior. Ask the search and catalog owners to locate the first unresolved comparison before expanding a traffic shift. Keep any missing observation open rather than replacing it with a performance target.

If the proposal instead concerns a managed domain's engine or inherited-index compatibility, use the OpenSearch upgrade and rebuild paper. That is a separate version-admission decision, not a procedure established by this historical self-managed case.

Technical reference

Amazon's caching and rollback-safety articles were checked on 18 October 2026 for the general failure considerations linked above. They do not identify this engagement's Elasticsearch version, node configuration, cache policy, migration settings or measured outcomes.