ஒரு collection endpoint-க்கு pagination, filtering, மற்றும் sorting-ஐ எப்படி design செய்வது?

Question

IT Interview Practice · Accepted Answer

ஒரு collection-ஐத் திருப்பும் எந்த endpoint-ம் முடிவுகளை வரம்பிட்டு வடிவமைக்க வேண்டும். மூன்று கவலைகள் — pagination, filtering, sorting — அனைத்தும் query string-இல் வாழ்கின்றன.

Pagination: offset vs cursor

Offset (page-based) — ?page=3&limit=20 அல்லது ?offset=40&limit=20.

## Pagination: offset vs cursor

**Offset (page-based)** — `?page=3&limit=20` அல்லது `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
எளிமையானது, எந்த page-க்கும் தாவ அனுமதிக்கிறது, ஆனால் scale-இல் இரண்டு சிக்கல்கள்: `OFFSET 100000` database-ஐ 100k rows-ஐ scan செய்து தூக்கியெறியக் கட்டாயப்படுத்துகிறது (மெதுவானது), மேலும் requests-க்கு இடையே rows insert/delete செய்யப்பட்டால், items **நகர்ந்து** நீங்கள் duplicates அல்லது skips பார்க்கிறீர்கள்.

**Cursor (keyset)** — client கடைசியாகப் பார்த்த item-க்கான ஒரு opaque pointer-ஐக் கடத்துகிறது.
```http
GET /orders?limit=20&cursor=eyJpZCI6MTAyMH0 HTTP/1.1
```
```http
HTTP/1.1 200 OK

{
  "data": [ /* 20 orders */ ],
  "page": { "next_cursor": "eyJpZCI6MTA0MH0", "has_more": true }
}
```
Server cursor-ஐ `WHERE id > 1020 ORDER BY id LIMIT 20` ஆக மொழிபெயர்க்கிறது — எந்த ஆழத்திலும் வேகமாக இருக்கும், inserts-க்கு எதிராக **நிலையான** ஒரு indexed lookup. Trade-off: "page 500"-க்கு random access இல்லை.

```text
Offset  → small datasets, admin UIs, "jump to page N"
Cursor  → large/infinite feeds, real-time data, mobile scroll
```

## Filtering மற்றும் sorting

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- field=value query params-உடன் **Filter** செய்யவும் (`status=shipped`). அனுமதிக்கப்பட்ட fields-ஐ whitelist செய்யவும்.
- ஒரு `sort` param-உடன் **Sort** செய்யவும்; ஒரு `-` முன்னொட்டு descending என்று பொருள் (`-created_at`). நிலையான வரிசைப்படுத்தலுக்கு multi-key-ஐ ஆதரிக்கவும்.
- எப்போதும் **`limit`-ஐ வரம்பிடவும்** (உ.ம். அதிகபட்சம் 100) ஒரு client ஒரு மில்லியன் rows-ஐக் கோர முடியாதபடி.

## இது ஏன் முக்கியம்

இது மிகவும் நடைமுறையான API-design கேள்விகளில் ஒன்று, ஏனெனில் கிட்டத்தட்ட ஒவ்வொரு list endpoint-ம் இதை எதிர்கொள்கிறது, மேலும் தேர்வுக்கு உண்மையான performance விளைவுகள் உள்ளன. Interviewer பொதுவாக **offset-vs-cursor trade-off**-ஐ ஆராய்கிறார்: எங்கும் offset pagination-ஐ நாடும் ஒரு candidate `OFFSET 1000000` table-ஐ scan செய்யும் வலியை உணரவில்லை, அல்லது ஒரு புதிய post insert செய்யப்பட்டதால் ஒரு infinite feed-ஐ scroll செய்யும் user அதே post-ஐ இரண்டு முறை பார்க்கும் "shifting results" bug-ஐ. Cursor pagination query-ஐ ஒரு indexed keyset lookup ஆக மாற்றுவதன் மூலம் இரண்டையும் சரிசெய்கிறது, அதனால்தான் ஒவ்வொரு large-scale API-ம் (Twitter, Stripe, Slack) feeds-க்கு அதைப் பயன்படுத்துகிறது. வலுவான பதில்கள் operational guardrails-ஐயும் குறிப்பிடுகின்றன — filter/sort fields-ஐ whitelist செய்தல் (unindexed queries மற்றும் injection-ஐத் தவிர்க்க) மற்றும் `limit`-ஐ வரம்பிடுதல் (database-ஐப் பாதுகாக்க) — இது இந்த endpoints-ஐ production-இல் இயக்கியவரை அவற்றைப் பற்றி மட்டுமே படித்தவரிடமிருந்து பிரிக்கிறது.

Pagination: offset vs cursor

Filtering மற்றும் sorting

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்