Understanding Deep Pagination Performance Issues in Elasticsearch and Its Distributed Architecture

Deep Pagination Performance Issue

When performing deep pagination in an Elasticsearch cluster, each shard must generate the top N results for the requested page, causing the coordinating node to sort a massive number of results and discard most of them, which dramatically increases CPU and memory consumption.

Why Deep Pagination Is Problematic

For example, requesting page 1 (results 1‑10) from an index with 5 primary shards requires each shard to return its top 10 results, which are then merged to select the final 10. Requesting page 1000 (results 10001‑10010) forces each shard to produce the top 10010 results, resulting in sorting 50,050 entries and discarding 50,040, illustrating the exponential resource growth with deeper pages.

Basic Concepts

Index

An index in Elasticsearch is analogous to a database; it stores documents and can be referenced by a lowercase name.

Type

Types act as logical partitions within an index, similar to tables in relational databases.

Document

Documents are JSON objects representing the atomic unit of data stored and searchable in an index.

Node

A running Elasticsearch instance is a node; a cluster consists of one or more nodes sharing the same cluster.name .

Master node: manages cluster-wide changes.

Data node: stores data and inverted indexes.

Coordinating node: routes client requests and balances load.

Shard

Data in an index is divided into primary and replica shards; each shard is a Lucene instance that handles its own indexing and search.

Distributed Document CRUD

Create (Index New Document)

The coordinating node determines the target shard for the new document, forwards the request to the primary shard, which then replicates it to its replicas.

Update and Delete

Updates are performed by indexing a new version of the document and marking the old version as deleted; deletions are recorded in a del file and only physically removed during segment merges.

Read (Search)

Search consists of a query phase, where each shard builds a priority queue of from + size results, and a fetch phase, where the coordinating node retrieves the actual documents from the relevant shards.

Segment Management

New documents are first written to memory and a transaction log ( translog ); every second a refresh creates a new segment in the filesystem cache. Periodic fsync writes segments to disk and clears the translog. Over time many small segments are merged into larger ones to improve search efficiency.