Build fluency in the vocabulary of paging through results without skipping or duplicating rows.
0 / 5 completed
1 / 5
At standup, a dev mentions an API returning a stable, opaque pointer alongside each page of results, letting the client request the next page by passing that pointer back instead of specifying a numeric page offset. What is this pagination technique called?
Cursor-based pagination returns a stable, opaque pointer alongside each page of results, and the client fetches the next page by passing that exact cursor back, rather than specifying a numeric page number or row offset. Offset-based pagination is the more familiar alternative that specifies a page number or row offset directly, which is simpler to implement but can behave inconsistently if rows are inserted or deleted between requests. This opaque-cursor approach is exactly what lets cursor-based pagination stay stable and consistent even as the underlying data set changes between page requests.
2 / 5
During a design review, the team picks cursor-based pagination over offset-based specifically because rows are frequently inserted into the underlying table while a user is actively paging through results. Which capability does the cursor-based approach provide here?
Cursor-based pagination provides avoiding skipped or duplicated rows across pages, since the cursor anchors each subsequent page request to a specific row's position in the result set, rather than a numeric offset, which shifts unpredictably if rows are inserted or removed ahead of the current page while the user is still paging through. Offset-based pagination, in the same scenario, can skip a row that shifted into an already-viewed offset, or show a duplicate that shifted into the next offset. This anchoring-to-position property is exactly why cursor-based pagination is preferred for a frequently changing data set.
3 / 5
In a code review, a dev notices an endpoint implements offset-based pagination by using a numeric page number to compute a database row offset for a table that receives frequent inserts at the top of the sort order. What does this represent?
This is a pagination consistency risk, since a numeric offset computed against a table that's actively receiving new rows at the top of the sort order can end up skipping a row that shifted position between page requests, or showing a duplicate row that shifted the other way, purely because the offset itself doesn't track any specific row's identity. A parameterized query is an unrelated defense from the SQL injection domain, not a pagination technique. This is exactly the scenario where cursor-based pagination's anchor-to-a-specific-row approach avoids the instability that a plain numeric offset introduces on a frequently changing table.
4 / 5
An incident report shows API consumers reported seeing duplicate and missing records while paging through a frequently updated feed, because the endpoint used offset-based pagination against a table receiving continuous inserts, and rows shifted position between successive page requests. What practice would prevent this?
Switching to cursor-based pagination, anchoring each page request to a specific row's stable position rather than a numeric offset, prevents newly inserted rows from shifting already-fetched results out of place or duplicating rows across pages, directly addressing the duplicate and missing records reported in this incident. Continuing to use offset-based pagination against a table receiving continuous inserts is exactly what caused the inconsistency described. This switch to cursor-based pagination is the standard fix for any frequently changing, actively paginated data set.
5 / 5
During a PR review, a teammate asks why the team implements cursor-based pagination instead of the simpler offset-based approach, given that offset-based pagination also lets a client jump directly to an arbitrary page number, which cursor-based pagination doesn't support as naturally. What is the reasoning?
Offset-based pagination's arbitrary-page-jump convenience comes directly at the cost of consistency on a frequently changing data set, since a numeric offset has no way to track a specific row's identity as the underlying table shifts around it. Cursor-based pagination trades away that jump-to-page-N convenience specifically to gain stable, gap-free results, since anchoring to a row's own position keeps working correctly even as unrelated rows are inserted or removed elsewhere in the table. The tradeoff is a genuine one, and it's why some APIs offer offset-based pagination for a relatively static data set where jump-to-page convenience matters more, while reserving cursor-based pagination for a feed or log that's actively and continuously changing.