The mechanics matter less than the consistency. The most common real-world failure is not choosing the theoretically wrong scheme; it is having four different pagination schemes across one portfolio because four teams each invented one.
Cursor-based pagination — an opaque token pointing at a position — is the right default for anything
large, high-volume, or actively changing. It is stable when records are inserted or deleted mid-walk,
and it does not get slower the deeper you go the way a large OFFSET does against most databases.
Offset and limit is fine for small, stable, human-facing collections where a consumer genuinely wants to jump to page seven. Be honest that it produces duplicate and skipped records when the underlying data changes between calls.
Whatever you pick, apply it identically everywhere, always return the pagination metadata in the same place with the same names, always include a link or token for the next page rather than making consumers construct one, set a default page size and a maximum, and say in the documentation what happens when the underlying data changes mid-pagination. That last one is the question every serious consumer will eventually hit, and almost nobody answers it.
