Scroll API for deep pagination in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Scroll API request?

Given the following Elasticsearch Scroll API request snippet, what will be the value of hits.total.value in the first scroll response?

Elasticsearch

{
  "size": 2,
  "query": { "match_all": {} }
}

POST /my_index/_search?scroll=1m

Response snippet:
{
  "_scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA...",
  "hits": {
    "total": {"value": 5, "relation": "eq"},
    "hits": [
      {"_id": "1", "_source": {"field": "value1"}},
      {"_id": "2", "_source": {"field": "value2"}}
    ]
  }
}

A 5

B 2

C 0

D undefined

💡 Hint

The total number of matching documents is returned in hits.total.value, not the number of hits in the current batch.

The hits.total.value field shows the total number of documents matching the query, which is 5 here. The hits.hits array contains only the current batch of 2 documents.

🧠 Conceptual

intermediate

Why use Scroll API instead of from/size for deep pagination?

Which of the following is the main reason to use the Scroll API for deep pagination in Elasticsearch instead of using from and size parameters?

A Scroll API allows updating documents during pagination.

B Scroll API automatically sorts results by relevance score.

C Scroll API is faster and more efficient for retrieving large numbers of documents sequentially.

D Scroll API caches all results in memory permanently.

💡 Hint

Think about performance when retrieving many documents beyond the first few pages.

The Scroll API is designed to efficiently retrieve large sets of documents by keeping a snapshot of the data and returning batches sequentially. Using from and size for deep pagination is inefficient because Elasticsearch must skip many documents each time.

🔧 Debug

advanced

Identify the error in this Scroll API usage

What error will occur when running the following sequence of Elasticsearch Scroll API calls?

Elasticsearch

POST /my_index/_search?scroll=1m
{
  "size": 3,
  "query": { "match_all": {} }
}

POST /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "incorrect_scroll_id"
}

A 404 Not Found error because the scroll ID is invalid or expired.

B No error; the scroll returns the next batch of results.

C Timeout error because the scroll duration is too short.

D SyntaxError due to malformed JSON in the scroll request.

💡 Hint

Consider what happens if you provide a wrong or expired scroll ID.

If the scroll ID is invalid or expired, Elasticsearch returns a 404 error indicating the scroll context was not found. This is common if the scroll ID is mistyped or the scroll timeout expired.

📝 Syntax

advanced

Which Scroll API request syntax is correct?

Choose the correct syntax for requesting the next batch of results using the Scroll API.

A

POST /my_index/_search/scroll
{
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA..."
}

B

POST /_search/scroll
{
  "scroll": "2m",
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA..."
}

C GET /_search/scroll?scroll=2m&scroll_id=DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA...

D

POST /_search/scroll
{
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA...",
  "timeout": "2m"
}

💡 Hint

Check the official Scroll API syntax for the request body and HTTP method.

The correct syntax uses a POST request to /_search/scroll with a JSON body containing scroll (the keep-alive time) and scroll_id. Option B uses GET which is invalid. Option B uses an incorrect endpoint. Option B uses an invalid parameter timeout instead of scroll.

🚀 Application

expert

How many documents are retrieved after 3 scroll requests?

You run a Scroll API search with size set to 4 on an index with 10 matching documents. You perform 3 scroll requests (initial search + 2 scrolls). How many documents have you retrieved in total?

A 6

B 8

C 12

D 10

💡 Hint

Multiply the batch size by the number of scroll requests, but consider the total documents available.

The initial search returns the first 4 documents, the first scroll returns the next 4, and the second scroll returns the remaining 2 documents (10 total). Total retrieved after 3 requests: 10 documents.