Redis pagination strategy for infinite scrolling page

Question

TL;DR: which of the three options below is the most efficient for paginating with Redis?

I'm implementing a website with multiple user-generated posts, which are saved in a relational DB, and then copied to Redis in form of Hashes with keys like site:{site_id}:post:{post_id}.

I want to perform simple pagination queries against Redis, in order to implement lazy-load pagination (ie. user scrolls down, we send an Ajax request to the server asking for the next bunch of posts) in a Pinterest-style interface.

Then I created a Set to keep track of published posts ids, with keys like site:{site_id}:posts. I've chosen Sets because I don't want to have duplicated IDs in the collection and I can do it fastly with a simple SADD (no need to check if id exists) on every DB update.

Well, as Sets aren't ordered, I'm wheighting the pros and cons of the options I have to paginate:

1) Using SSCAN command to paginate my already-implemented sets

In this case, I could persist the returned Scan cursor in the user's session, then send it back to server on next request (it doesn't seem reliable with multiple users accessing and updating the database: at some time the cursor would be invalid and return weird results - unless there is some caveat that I'm missing).

2) Refactor my sets to use Lists or Sorted Sets instead

Then I could paginate using LRANGE or ZRANGE. List seems to be the most performant and natural option for my use case. It's perfect for pagination and ordering by date, but I simply can't check for a single item existence without looping all list. Sorted Sets seems to join the advantages of both Sets and Lists, but consumes more server resources.

3) Keep using regular sets and store the page number as part of the key

It would be something like site:{site_id}:{page_number}:posts. It was the recommended way before Scan commands were implemented.

So, the question is: which one is the most efficient / simplest approach? Is there any other recommended option not listed here?

Answer 1

"Best" is best served subjective :)

I recommend you go with the 2nd approach, but definitely use Sorted Sets over Lists. Not only do the make sense for this type of job (see ZRANGE), they're also more efficient in terms of complexity compared to LRANGE-ing a List.