Welcome to the next exciting part of our Redis-based backend system project. In this unit, we will focus on building leaderboard functionality using Redis sorted sets. Building a leaderboard is a popular use case for many applications, such as games and competitive platforms. You've already connected to Redis and stored basic values; now we'll build on that foundation.

Let's briefly review what we'll focus on in this unit. Our main tasks will be:

1. Adding user scores to a leaderboard: We will store user scores using Redis sorted sets.
2. Retrieving the leaderboard: We will fetch and display the top users and their scores.
3. Getting a user's rank and score: We will retrieve the ranking and score of a specific user.

We start by creating the Asio event loop, opening a Redis connection, and preparing the request and response objects. The request will hold all Redis commands we want to send, and the response<...> type describes the result type for each command in the same order.

In this section, the main idea is that Boost.Redis lets us describe the expected reply types ahead of time. That is why response<...> contains one entry per Redis command.

A few useful points here:

• Pipelining commands: instead of sending commands one by one, we collect them into a single request. Redis can process them together, which reduces network round-trips.

Next, we add all the commands we want to execute. This includes storing some user profile data, adding leaderboard scores, reading the top users, and asking for one user's rank and score.

This section shows the Redis commands that power the leaderboard:

• SETEX stores a value and sets its expiration time in the same command. Here, it saves profile data for user3 with a lifetime of 86400 seconds (1 day).
• ZADD adds or updates a member in a sorted set with a numerical score. This is why sorted sets are a natural fit for leaderboard data.
• ZREVRANGE reads members in descending score order. With "0" and "2", we ask for the top 3 entries by index.
• WITHSCORES tells Redis to include both member names and scores in the reply.
• ZREVRANK returns a member's , where the highest score has rank .

Finally, we send all commands to Redis, inspect the typed results, print the leaderboard, and close the connection gracefully.

Here we execute the whole pipeline with async_exec. Because the response type matches the command order, we can use std::get<N>(*resp) to access each result by position:

• std::get<0>(*resp) is the SETEX result
• is the result

In this lesson, you used Redis sorted sets to model a leaderboard, which is a natural fit because each member is stored together with a score and ordered automatically. You saw how to add or update scores with ZADD, retrieve top-ranked users with ZREVRANGE ... WITHSCORES, and inspect an individual player with ZREVRANK and ZSCORE.

You also reinforced an important Boost.Redis pattern: building a single request with multiple commands and executing it as a pipeline. This improves efficiency and keeps related operations grouped together. On the C++ side, you matched each Redis command to a corresponding entry in a typed response<...> and accessed those results safely with std::get<N>.

At this point, you have the core building blocks for leaderboard features in a backend system: storing scores, reading rankings, and looking up player-specific stats. In the next practice tasks, you'll apply these ideas directly so they become familiar through implementation.