একটি collection endpoint-এর জন্য আপনি কীভাবে pagination, filtering, আর sorting design করেন?

Question

IT Interview Practice · Accepted Answer

যেকোনো endpoint যা একটি collection ফেরত দেয় তার ফলাফল সীমিত ও আকৃতি দেওয়া দরকার। তিনটি উদ্বেগ — pagination, filtering, sorting — সবই query string-এ থাকে।

Pagination: offset বনাম cursor

Offset (page-ভিত্তিক) — ?page=3&limit=20 বা ?offset=40&limit=20।

## Pagination: offset বনাম cursor

**Offset (page-ভিত্তিক)** — `?page=3&limit=20` বা `?offset=40&limit=20`।
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
সরল এবং যেকোনো page-এ লাফানোর অনুমতি দেয়, কিন্তু বড় মাপে দুটি সমস্যা: `OFFSET 100000` database-কে 100k row scan করে ফেলে দিতে বাধ্য করে (ধীর), এবং request-এর মধ্যে row insert/delete হলে item **সরে যায়** এবং আপনি ডুপ্লিকেট বা বাদ দেখেন।

**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 যা যেকোনো গভীরতায় দ্রুত থাকে এবং insert-এর বিরুদ্ধে **স্থিতিশীল**। ট্রেড-অফ: "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 param দিয়ে **Filter** করুন (`status=shipped`)। অনুমোদিত field whitelist করুন।
- একটি `sort` param দিয়ে **Sort** করুন; একটি `-` prefix মানে descending (`-created_at`)। স্থিতিশীল ordering-এর জন্য multi-key সমর্থন করুন।
- সবসময় **`limit` সীমিত করুন** (যেমন সর্বোচ্চ 100) যাতে একটি client লক্ষ লক্ষ row চাইতে না পারে।

## এটি কেন গুরুত্বপূর্ণ

এটি সবচেয়ে ব্যবহারিক API-design প্রশ্নগুলোর একটি কারণ প্রায় প্রতিটি list endpoint এতে ঠেকে, এবং পছন্দের বাস্তব performance পরিণতি আছে। Interviewer সাধারণত **offset-বনাম-cursor ট্রেড-অফ** খুঁটিয়ে দেখেন: যে candidate সর্বত্র offset pagination-এ হাত বাড়ায় সে `OFFSET 1000000` table scan করার ব্যথা অনুভব করেনি, বা "shifting results" bug যেখানে একটি infinite feed scroll করা user একই post দুবার দেখে কারণ একটি নতুন post insert হয়েছিল। Cursor pagination query-কে একটি indexed keyset lookup-এ পরিণত করে দুটোই ঠিক করে, সেজন্যই প্রতিটি বড়-মাপের API (Twitter, Stripe, Slack) feed-এর জন্য এটি ব্যবহার করে। শক্তিশালী উত্তর operational রক্ষাকবচগুলোও উল্লেখ করে — filter/sort field whitelist করা (unindexed query আর injection এড়াতে) এবং `limit` সীমিত করা (database রক্ষা করতে) — যা এই endpoint production-এ চালানো কাউকে শুধু এদের সম্পর্কে পড়া কারও থেকে আলাদা করে।

Pagination: offset বনাম cursor

Filtering আর sorting

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন