Challenge 3: Justify Cursor Pagination for /v1/tasks — Possible Solution ==================================================================== WHY OFFSET/LIMIT WOULD CONCRETELY BREAK HERE ------------------------------------------------- The scenario states tasks are "added and completed constantly by many users at once." Picture a client fetching page one with ?offset=0&limit=20, planning to fetch ?offset=20&limit=20 next. In the time between those two requests, if even ONE new task is created near the front of the list (which, with many users active simultaneously, is highly likely), every task after it shifts by one position. The client's second request, still asking for "offset 20 onward," now starts one position later than it should — meaning the LAST task the client saw on page one gets shown to them AGAIN on page two (a duplicate), or in the reverse case (a task removed near the front), a task gets skipped entirely and the client never sees it in either page. WHY CURSOR-BASED PAGINATION AVOIDS THIS -------------------------------------------- Cursor-based pagination (?after=&limit=20) doesn't count positions from the start of the list at all — the cursor refers to a specific task's position directly (e.g., "everything after task id 520"). Even if tasks are added or removed elsewhere in the list while the client is paginating, that reference point doesn't shift, so the client's next page reliably continues exactly where the last one left off, regardless of how much churn is happening elsewhere in the data. WHY THIS WORKS AS AN ANSWER ------------------------------ The justification has to connect to the SPECIFIC property of this platform (many users changing the task list constantly) rather than just restating "cursor pagination is generally better." Cursor pagination's real advantage — stability under a constantly-changing dataset — is exactly the property this platform's usage pattern requires, which is precisely why the capstone chose it deliberately rather than defaulting to the simpler offset/limit approach.