Pagination Strategies: Offset, Cursor, and Infinite Scroll

The plain-language idea

Pagination splits a large list into pages the client fetches incrementally, and there are two fundamentally different ways to say "give me the next page":

• Offset-based pagination — "skip N items, give me the next M." Simple to implement and reason about, and it's the only shape that naturally supports jumping straight to an arbitrary page ("show me page 12"). Its real weakness surfaces when the underlying dataset changes between requests: if items are added or removed ahead of where you're paging, the positions everything sits at shift, and "skip N" now points at different items than it did a moment ago.
• Cursor-based pagination — "give me everything after item X," where X is a specific item's identity (an id, or an opaque token derived from one), not a numeric position. Because the request is anchored to an item rather than a position count, it's immune to the shifting problem: inserting or removing items elsewhere in the list doesn't change what "after X" means. The tradeoff is real too — there's no direct way to jump to "page 12" with a cursor, only to move forward or backward relative to a known item.

Infinite scroll is a UI pattern, not a pagination strategy in itself — it's the presentation layer (load more automatically as the user nears the bottom) built, in most real implementations, on top of cursor-based pagination underneath, precisely because a continuously-scrolling feed is exactly the case where the underlying data keeps changing while someone is mid-scroll.

See it in a real thing: a list that changes while you're paging through it

A list shows A-F, newest first. Page 1 (offset 0, take 3) already returned A, B, C. Page 2 requests offset 3, take 3 — items D, E, F.

BackNext

Picture a list of six items, newest first, where page 1 (offset 0, take 3) has already been fetched and shown. Before page 2 is requested, a new item gets inserted at the front. With offset pagination, the page-2 request still says "skip 3" — but since everything shifted by one, that request now returns an item already shown on page 1 (a duplicate) and never returns the item that should have been last on page 1 before the shift (a skip). This isn't a rare edge case in a feed or list that receives writes while being read — it's the expected behavior of offset pagination under exactly that condition. Cursor-based pagination sidesteps it entirely: a request for "everything after item C" still means the same thing regardless of what got inserted elsewhere, because it's anchored to C's identity, not a position.

What people usually miss

Watch out

• The offset bug is a correctness problem, not a performance one. A candidate who frames this purely as "offset is a bit slower on large tables" is missing the actual failure mode this lesson is about: users silently seeing duplicated or missing items, which is a data-integrity issue, not a speed issue.
• Cursor pagination's lost jump-to-page-N isn't a minor inconvenience to wave away. It's a genuine, sometimes user-facing tradeoff — an admin dashboard that needs "go to page 40" as a real feature is a legitimate reason to accept offset's shifting-data risk, if the dataset is stable enough that risk rarely materializes.
• Infinite scroll is a UI decision layered on top of a pagination strategy, not a third alternative to offset and cursor. Conflating them is a common but revealing mistake — the interview-worthy answer names the pagination strategy underneath the scroll behavior.
• A cursor doesn't have to be a raw database id. It's commonly an opaque, encoded token the server controls the meaning of — this keeps the client from needing to understand or depend on the underlying storage's specifics.

Why this matters in interviews

"How would you paginate this list?" is a near-universal follow-up to any feed or list-heavy system design prompt, and the strongest answers explain the offset-vs-cursor choice as a correctness tradeoff tied to whether the dataset changes while being paged, not a generic "cursor is more modern" preference.