Pagination Technique | System Design | iOS

Today’s applications require pagination as one of their core capabilities. Pagination reduces the load on the server and frontend.

Pagination also improves the user experience by allowing users to quickly access and view the content they need. Additionally, pagination is more efficient in terms of data usage, as it only loads the content that is necessary for the user.

Pagination can be done in a variety of ways. The most popular is

1 — Offset and limit

The limit option allows you to limit the number of rows returned from a query. In contrast, offset allows you to omit a specified number of rows before the beginning of the result set. Using both limit and offset skips both rows and limits the rows returned.

{
  "total_results": 1000,
  "offset": 20,
  "limit": 10,
  "data": [
    {
      "id": 1,
      "name": "John"
    },
    {
      "id": 2,
      "name": "Jane"
    },
    ...
  ]
}

Advantages of the above mechanism:-

• You know total count in advance
• Because you know how much data there is, you can jump around between pages

Disadvantages of the above mechanism:-

• Each time, the server needs to scan data from the beginning to get to the next page
• Incontinency if there is a write operation in the paginated table. To fix this, developer bring’s feed page to 0.
• If there is an update on server, you need to refresh the page to initial state.
• We cannot implement Forward and backward pagination

2 — Cursor-based pagination:-

Instead of storing the current OFFSET and LIMIT locally and passing it on with each request, you should store the last received primary key (usually an ID/timestamp) and the LIMIT. If the last received primary key is null, we assume pagination is over.

There is another variation of cursor based pagination :-
- Get previous page cursor

{ "ok": true, 
"time_stamp": 1499767272, 
"response_metadata": 
{ 
"next_cursor": "dXNlcjpXMDdRQ1JQQTQ=" , 
"previous_cursor:"dXFwSD2lCTE1JQQTQ="} 
}

3rd variation:-
- URL instead of primary key in cursor

{ 
"ok": true, 
"time_stamp": 1499767272, 
"response_metadata": { "next_cursor_URL": "URL" , 
"previous_cursor_URL:"URL2"
} 
}

Based on the availability of the server || congestion in the server, it might be you can’t request the next page from same server at the same time.This technique can help to reduce load to one server.

Advantage:-

• You can fetch a paginated data in both ways
• Performance improvement
• Remove inconstent issue in offset paginating techniques
• Application like chatting, we can directly move to the exact location of the chat and utilize forward and backward pagination feature.

Disadvantage:-

• Unique identifier required for the next/previous cursor. If data is fetched from multiple sources, it might be challenging to implement in the backend.
• We cannot know the total count in advance, so jumping from one page to another is impossible.