Returning results in pages rather than all at once, so a search for a common term doesn't try to send ten thousand items.
Why it exists
A list can grow to thousands or millions of rows, and sending them all at once would be slow to fetch, heavy to render, and useless to a person who reads the first ten. Loading everything to show a screenful is waste. Pagination exists to return results in bounded pages, so the client asks for only what it will show and fetches more on demand.
How it actually works
Asking for every matching product at once is slow to load and wasteful. Pagination returns a manageable chunk, say 20, plus a way to fetch the next chunk when the user scrolls or clicks.
This is why long lists load a screenful at a time and fill in as you go. The server and the network only handle what the user actually looks at.
A senior PM walks you through it
A junior PM, stuck
The orders export keeps timing out, and the dev's one-line diagnosis was "no pagination, it pulls all 40,000 rows at once." That sentence means nothing to me, and I have to explain the fix to my lead in standup tomorrow. I do not know what pagination looks like or why pulling everything is the problem.
The export dies because it asks the database for every row in one go and then waits, and waits. Pagination is the ordinary fix: ask for a small page at a time and loop until you run out. It is easier to see than to describe. I captured a paged call to the orders list, the request with its two knobs and the response that tells you how to get the next page. Read it and you will explain this better than the dev did.
GET /api/orders?page=1&limit=20, one page of the export
Request and response
11201.1
2
31.1200
4{
5"meta":{
6"total":40000,
7"page":1,
8"per_page":20,
9"next_page":2
10},
11"orders":[
12{"order_id":"o_5512","amount":649},
13{"order_id":"o_5513","amount":649},
1418,20
15]
16}
Click a step to see the lines it points at.
Mistakes I've seen
Explaining the timeout as "the server is slow" instead of "it fetches everything at once." The fix is not a faster server, it is asking for pages. Naming the real cause points the dev at the right change.
Assuming pagination is only a backend detail. Whether the user sees infinite scroll or numbered pages changes how people browse and find things, and that is a product decision, not a purely technical one.
Speccing a list feature with no page size. Without a limit, the first popular query tries to return thousands of rows and the screen crawls. Decide the page size when you design the list, not after it breaks.
Reading a short response as the complete set. Twenty rows came back, but total said 40000. If you skip the meta, you will file a bug about missing data when the data is just on the next page.
In standup, say: "The export pulls all 40,000 rows in one request, so it times out. The fix is pagination: fetch 20 rows a page and loop using next_page until there are none left." You read the real request and response, so you are not repeating the dev, you are explaining it. That is pagination.
Where a PM meets this
"Infinite scroll" and "page 2" are both pagination. Which one you choose is a product decision affecting how people browse.
Reports and exports that "time out" often do so because they skipped pagination and tried to pull everything at once.
Hear it in a meeting
"The export is timing out, it's pulling all 40,000 rows with no pagination."