एका 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-आधारित) — ?page=3&limit=20 किंवा ?offset=40&limit=20.

## Pagination: offset vs cursor

**Offset (page-आधारित)** — `?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` मध्ये भाषांतर करतो — एक indexed lookup जे कोणत्याही खोलीवर वेगवान राहते आणि inserts विरुद्ध **stable** असते. तडजोड: "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 करा**; `-` prefix म्हणजे उतरता क्रम (`-created_at`). स्थिर क्रमासाठी multi-key ला support द्या.
- नेहमी **`limit` वर मर्यादा घाला** (उदा. कमाल 100) जेणेकरून client दशलक्ष rows मागू शकणार नाही.

## हे का महत्त्वाचे आहे

हा सर्वात व्यावहारिक API-design प्रश्नांपैकी एक आहे कारण जवळपास प्रत्येक list endpoint याला भेटतो, आणि निवडीचे खरे performance परिणाम असतात. Interviewer सहसा **offset-vs-cursor trade-off** तपासत असतो: सर्वत्र offset pagination वापरणाऱ्या उमेदवाराने table scan करणाऱ्या `OFFSET 1000000` चे दुःख अनुभवलेले नसते, किंवा "shifting results" bug जिथे infinite feed scroll करणाऱ्या वापरकर्त्याला नवे post insert झाल्यामुळे तेच post दोनदा दिसते. Cursor pagination query ला indexed keyset lookup बनवून दोन्ही दुरुस्त करते, म्हणूनच प्रत्येक मोठ्या-प्रमाणातील API (Twitter, Stripe, Slack) ते feeds साठी वापरते. चांगली उत्तरे operational संरक्षकांचादेखील उल्लेख करतात — filter/sort fields whitelist करणे (unindexed queries आणि injection टाळण्यासाठी) आणि `limit` वर मर्यादा (database चे रक्षण करण्यासाठी) — जे या endpoints production मध्ये चालवलेल्या व्यक्तीला केवळ त्यांबद्दल वाचलेल्या व्यक्तीपासून वेगळे करते.

Pagination: offset vs cursor

Filtering आणि sorting

हे का महत्त्वाचे आहे

संबंधित प्रश्न