Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why does offset-based pagination become progressively slower for pages deep into a large dataset (e.g. page 5,000), compared to page 1?
💻 Code Challenge | +75 XP
Implement a GET /orders endpoint with offset-based pagination including explicit ordering by id, page/pageSize query parameters, and an optional total count that's skipped for result sets over a defined size threshold.
A client fetching pages of a frequently-updated order list occasionally sees the same order appear on two consecutive pages, or an order disappear entirely between pages. Reorder the steps to diagnose and understand this offset-pagination limitation.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant

Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Implementing pagination with no explicit, deterministic ORDER BY clause
// Wrong: undefined ordering between requests
Order.findAll({ limit: 20, offset: 20 });
// Correct: explicit, deterministic ordering
Order.findAll({ limit: 20, offset: 20, order: [["id", "ASC"]] });The Solution //
Without an explicit order on a unique or near-unique column, the database is free to return rows in any order it finds internally convenient, which can vary between queries — meaning consecutive page requests aren't even guaranteed to be consistent with each other, let alone stable across concurrent writes.
The Error //
Using deep offset pagination (e.g. page 5000) on a very large table without recognizing the performance cost
// Scales poorly: DB scans and discards 100,000 rows first
Order.findAll({ limit: 20, offset: 100000 });
// Consider cursor-based pagination for very large, deeply-paged datasetsThe Solution //
The database must scan and discard every row before the requested offset, meaning query time grows with how deep into the dataset the client is paging, not just with the page size — a query that's fast on page 1 can become genuinely slow by page 5000 on a large table.