Why Traditional PageSize/PageIndex Pagination Breaks with Dynamic Data—and How to Fix It

1. Problem Analysis

Many developers implement pagination by sending pageSize and pageIndex from the client to the server, but few resources explain the hidden issues of this approach.

Pagination fundamentally retrieves a continuous slice of a list based on a start and end position, regardless of sorting complexity. Whether using raw SQL or a search engine like Elasticsearch, the client ultimately expects the next page of results.

Various UI patterns (e.g., infinite scroll, waterfall flow) can display paginated data, but when the total record count is irrelevant, the server should avoid counting it and simply rely on the presence of data in the next page.

2. Problem Identification

Consider a simple SQL pagination example. Original data set: 1,2,3,4,5,6,7 Sorted descending: 7,6,5,4,3,2,1 Requesting page 2 with pageSize=2 and pageIndex=2 correctly returns 5,4. If a new record 8 is inserted, the list becomes 8,7,6,5,4,3,2,1 Now the same request returns 6,5, causing a mismatch.

The root cause is that pagination operates on dynamic data; changes within the requested range lead to duplicate or missing rows.

3. Solution

Because the data source is mutable, the client and server must adopt strategies to avoid inconsistencies.

3.1 Client Side

The client should keep a list of primary keys for already displayed records and de‑duplicate any newly fetched rows that have appeared before.

Note: Maintaining a full key pool may be impractical for very large data sets.

3.2 Server Side

(1) Add a lastId parameter (the ID of the last record from the previous page) and drop pageIndex. With lastId, the server can directly locate the start point.

(2) Cache the entire result set temporarily to provide a quasi‑static view, though this only mitigates the problem.

(3) If ordering is not critical, use sequential pagination that fetches data from a stable segment.

3.3 Business Side

Accept that occasional duplicate records may occur if the product or operations teams can tolerate them, thereby reducing the engineering burden.

Sometimes what appears as a data bug to developers is not a critical issue for other business units.