ElasticSearch Communication & Stakeholder Relations 4 — Questions and Answers
Question 1: A stakeholder asks why the team needs a dedicated 'hot-warm' architecture instead of one uniform cluster. How do you explain the cost-performance trade-off?
- Hot-warm architecture splits the cluster into two separate Elasticsearch clusters with no communication
- Recent data on fast SSD nodes (hot) handles high-throughput indexing and search, while older data moves to cheaper HDD nodes (warm), reducing storage costs without sacrificing query speed on fresh data (Correct answer)
- Hot nodes handle writes only; warm nodes handle reads only, regardless of data age
- Hot-warm requires a separate license tier and is not available in open-source Elasticsearch
Correct answer: Recent data on fast SSD nodes (hot) handles high-throughput indexing and search, while older data moves to cheaper HDD nodes (warm), reducing storage costs without sacrificing query speed on fresh data
Hot-warm tiering aligns hardware cost to data access patterns, keeping recent high-value data on performant nodes and aging data on cost-effective storage.
Question 2: During a sprint review, a developer asks how the Elasticsearch _bulk API improves communication efficiency over individual index requests. What is correct?
- The _bulk API compresses documents using gzip before sending them to the cluster
- The _bulk API batches multiple index, update, or delete operations into a single HTTP request, reducing network round-trip overhead and improving throughput (Correct answer)
- The _bulk API automatically detects duplicate documents and skips reindexing them
- The _bulk API bypasses the translog for faster writes
Correct answer: The _bulk API batches multiple index, update, or delete operations into a single HTTP request, reducing network round-trip overhead and improving throughput
Batching operations in a single _bulk request dramatically reduces per-operation HTTP overhead, which is critical for high-volume ingestion pipelines.
Question 3: A data governance stakeholder asks how to ensure sensitive fields like Social Security Numbers are never stored in plain text in Elasticsearch. What is the recommended approach?
- Set the field type to 'encrypted' in the index mapping
- Use an ingest pipeline with a script or integration at the application layer to hash or redact the field before it reaches Elasticsearch, and restrict index access with role-based security (Correct answer)
- Elasticsearch automatically detects and masks PII fields based on their names
- Disable the translog to prevent sensitive data from being written to disk
Correct answer: Use an ingest pipeline with a script or integration at the application layer to hash or redact the field before it reaches Elasticsearch, and restrict index access with role-based security
Sensitive data should be masked or hashed before ingestion, combined with role-based access control to prevent unauthorized field-level access.
Question 4: A stakeholder wants to understand how Elasticsearch handles a request when the cluster is under heavy load. What concept should you explain?
- Elasticsearch queues all incoming requests in a persistent database until resources free up
- Elasticsearch uses thread pools for different operation types; when a pool's queue fills up, new requests are rejected with a 429 error to prevent cascading failures (Correct answer)
- Heavy load triggers automatic node scaling through Kubernetes by default
- Elasticsearch pauses indexing automatically and prioritizes search during high load
Correct answer: Elasticsearch uses thread pools for different operation types; when a pool's queue fills up, new requests are rejected with a 429 error to prevent cascading failures
Thread pool queue limits cause 429 rejections under sustained overload, which is a design choice to protect cluster stability rather than silently degrading.
Question 5: A business analyst asks what 'aggregations' in Elasticsearch enable that raw search results do not. What is the most accurate explanation?
- Aggregations allow Elasticsearch to modify documents in bulk without reindexing
- Aggregations compute analytics like counts, averages, histograms, and term frequency distributions over search result sets, enabling dashboards without exporting data to another system (Correct answer)
- Aggregations are required to enable full-text search on numeric fields
- Aggregations create materialized views that are stored as new indexes
Correct answer: Aggregations compute analytics like counts, averages, histograms, and term frequency distributions over search result sets, enabling dashboards without exporting data to another system
Aggregations provide real-time analytics on indexed data, allowing metrics and groupings to be computed server-side without transferring raw documents.
Question 6: A stakeholder asks why a reindex operation is required when changing an analyzed field's mapping. What explanation is correct?
- Elasticsearch prohibits updating mappings entirely, so a new cluster must be created
- Mappings for analyzed fields cannot be changed in place because existing documents were tokenized under the old analyzer; reindexing re-processes them under the new mapping (Correct answer)
- A reindex is needed only when changing numeric field types, not text analyzers
- Reindexing is optional if the cluster has at least three nodes
Correct answer: Mappings for analyzed fields cannot be changed in place because existing documents were tokenized under the old analyzer; reindexing re-processes them under the new mapping
Inverted indexes are built at index time using the configured analyzer; changing the analyzer requires reprocessing existing documents to rebuild those indexes correctly.
Question 7: An operations team lead asks when it is safe to perform a rolling restart of an Elasticsearch cluster. What prerequisite should you communicate?
- A rolling restart is only safe when the cluster has zero active search requests
- Before a rolling restart, disable shard allocation to prevent unnecessary shard movements during the restart, then re-enable it after each node rejoins (Correct answer)
- Rolling restarts require all indexes to be closed first to avoid data loss
- A rolling restart requires taking a full snapshot and verifying it before proceeding
Correct answer: Before a rolling restart, disable shard allocation to prevent unnecessary shard movements during the restart, then re-enable it after each node rejoins
Disabling shard allocation before restarting each node prevents Elasticsearch from unnecessarily moving shards, reducing the recovery time and cluster load.
ElasticSearch Communication & Stakeholder Relations 4
A stakeholder asks why the team needs a dedicated 'hot-warm' architecture instead of one uniform cluster.
How do you explain the cost-performance trade-off?