Pagination looks trivial when all you need is page=3&per_page=20 in a CRUD screen. It stops being trivial the moment the same dataset starts serving customer search, CSV exports, background sync jobs, and admin tooling with different correctness requirements. That is when a list endpoint quietly turns into infrastructure. The problem is not pagination itself. The problem is pretending one pagination strategy can satisfy every consumer equally well. It cannot. Offset pagination, cursor pagination, keyset pagination, snapshot exports, and bulk traversal each solve different problems. If you force one model across all of them, you usually end up with slow queries, duplicate rows, missing rows, broken exports, or admin screens that feel inconsistent under load. The practical rule is simple: paginate by product need, not by frontend habit . If a list is customer-facing and needs numbered pages, optimize for navigation clarity. If a job needs to walk millions of rows safely, optimize for traversal stability.…