I first saw Redis sorted sets in action reading Mastodon’s source code. Sorted sets are used to store feeds (ignore that ZREVRANGEBYSCORE is deprecated). In a use-case such as Mastodon feeds (timelines), sorted sets come handy because you can “just” add new elements and Redis will take care of the sorting.

In a sorted set each element has a “score” that’s used for sorting. In the case of a timeline, the score could be either the timestamp of the post or the ID of the post if post IDs are strictly sorted (a MySQL auto_increment or similar). The “member” (element) could be the ID of the post or even the whole post itself if that’s how you roll. Since Mastodon uses the toot’s ID as the score, timelines are actually sorted by time of arrival instead of the actual “published” timestamp of the toot (eg if a federated toot arrives very late it’s still gonna go to the top of the feed instead of the middle where it’d belong by its timestamp).

While sorted sets are a full-fledged Redis feature meaning they have solid and reliable performance, they’re still “slow” (really not slow) with an O(log n) time complexity. Scratch that, chances are that unless you have absolutely humongous sorted sets you won’t notice anything and even then O(log n) is a very good price to pay for such a rich feature. What I’ve seen of them so far at least they leave any SQL query in the dust I could come up with to achieve similar results.