[00:01] testing, but then in your production and users started to see duplicate posts. Why? Well, you were using what's called offset pagination. A query like limit offset pagination. A query like limit 10, offset by 1,000. It skips N rows and
[00:13] simple and it's the default for most systems, but it has two big problems at scale. First, the database still scans every skipped row. At offset 500,000, you're throwing away half a million rows on every request. Second, this is where
[00:28] our duplicate bug came in. If a new post gets inserted while a user is scrolling, every row shifts down by one. So, the post that was at position 10 is now at position 11. Next page starts at offset 10 and you've served them the same post
[00:42] again. Or, if a row got deleted and you end up skipping one entirely. Cursor pagination fixes both of these issues. Instead of skip N rows, you say, "Give me everything after this item." Usually using the timestamp or the ID from the
[00:55] last item the client saw. So, the query becomes something more like this. The index seeks straight to the spot on disk, no scans, no shifting, and no fine for admin dashboards or small scale, but for any feed with real
[01:09] traffic, cursor-based pagination is a non-negotiable. Check out our full breakdown of pagination and API design over at hellonext.com.