Challenge 2: Design a Paginated Response — Possible Solution
====================================================================

REQUEST SHAPE
------------------------------
  GET /products?after=<cursor>&limit=20

  - `after`: the cursor from the previous page's response (omitted
    entirely on the very first request).
  - `limit`: how many items to return in this page (defaults to a
    sane value like 20 if omitted).

RESPONSE SHAPE
------------------------------
  {
    "items": [ { "id": 501, "name": "..." }, ... 20 items ... ],
    "next_cursor": "eyJpZCI6NTIwfQ==",
    "has_more": true
  }

  - `items`: the actual page of results.
  - `next_cursor`: an opaque token (often just an encoded reference
    to the last item's position, e.g. its id or a timestamp) the
    client passes back as `after` to get the following page.
  - `has_more`: lets the client know whether to bother requesting
    another page at all.

WHY CURSOR-BASED FITS BETTER HERE
------------------------------------
The dataset is explicitly described as changing constantly throughout
the day — items being added and removed. That's precisely the
scenario where offset/limit pagination breaks down, per this
chapter's gotcha: if an item is added near the front of the list
while a client is midway through paging with `?offset=20&limit=20`,
every item after that insertion point shifts by one position,
causing the next offset-based page to either skip an item or return
a duplicate the client already saw on the previous page.

Cursor-based pagination avoids this because `next_cursor` refers to a
STABLE position relative to a specific item (e.g. "everything after
product id 520"), not a numeric count of rows from the start. Even if
items are added or removed elsewhere in the list, that specific
reference point doesn't shift, so the client's pagination stays
consistent regardless of how much the underlying data changes between
requests.

WHY THIS WORKS AS AN ANSWER
------------------------------
The justification has to connect back to the SPECIFIC property of
this dataset (constant changes) rather than just asserting "cursor is
better" as a general rule — cursor-based pagination's real advantage
is durability under a changing dataset, which is exactly the
condition this scenario describes.