Cursor pagination

Your infinite scroll feed works great in testing. Then it hits production and users start seeing duplicate posts. Why?

You're using offset pagination. LIMIT 10 OFFSET 1000 — skip N rows, return the next page. Simple, and it's probably what your ORM does by default.

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 — and this is your duplicates bug — if a new post gets inserted while a user is scrolling, every row shifts down by one. The post that was at position 10 is now at position 11. Next page starts at offset 10... and serves them the same post again. Or, if rows get deleted, they skip one entirely.

Cursor pagination fixes both. Instead of "skip N rows," you say "give me everything after this item," using the timestamp or ID from the last item the client saw. WHERE createdat [ cursor ORDER BY createdat DESC LIMIT 10. The index seeks straight to that spot on disk. No scans, no shifting, no duplicates.

Offset is fine for admin dashboards. For any feed with real traffic, cursor pagination is non-negotiable.

Check out our full breakdown of pagination and API design for system design interviews at Hello Interview. #shorts

Видео Cursor pagination канала Hello Interview