Elasticsearch hard
Elasticsearch features multiple 'Circuit Breakers'. What is the proactive mechanism used by the 'Request' breaker to prevent a node crash?
- A It terminates any thread that has been running for more than 30 seconds.
- B It estimates the memory requirements of an incoming query *before* execution. If the estimated cost + current usage exceeds the breaker limit, it rejects the request with a 429 error.
- C It monitors the temperature of the physical server CPUs.
- D It automatically scales the number of shards in the index to spread the load.
Answer: B. It estimates the memory requirements of an incoming query *before* execution. If the estimated cost + current usage exceeds the breaker limit, it rejects the request with a 429 error.
The breakers are 'Statistical Guardrails'. By predicting that a massive aggregation will need 10GB of Heap when only 2GB is left, Elasticsearch can protect itself from the 'Stall of Death' where a node spends 100% of its time doing Garbage Collection and stops responding to health checks.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What are the two primary reasons for configuring one or more 'Replica Shards' for an index?
- When a String field is mapped as `text`, what process is performed to enable full-text search capability?
- What is the primary benefit of splitting an Elasticsearch index into multiple 'Primary Shards'?
- Every document stored in an Elasticsearch index is uniquely tracked by which mandatory metadata field?
- Elasticsearch search results include a metadata field called `_score`. What does this value primarily indicate?
- What is the primary architectural purpose of Elasticsearch in a modern software stack?