Batching Commands with Boost.Redis

Introduction

In this lesson, we'll learn how to batch multiple commands using Boost.Redis . Instead of sending commands one at a time and waiting for each response, we'll group several commands together and send them in a single request. This is one of the most powerful techniques for improving Redis performance. We'll build a practical example that demonstrates: Batching INCR and SET commands in one request Receiving and printing the result of each batched command Batching two GET commands in a second request to read back the values Using focused completion handlers to process each batch's results

Understanding Command Batching

Why batch commands? When you send commands one at a time, each command requires a separate network round trip to the Redis server: Send command 1 \to Wait for response 1 Send command 2 \to Wait for response 2 Send command 3 \to Wait for response 3 With batching, you send all commands together in one network round trip: Send commands 1, 2, 3 \to Wait for responses 1, 2, 3 This dramatically reduces network latency and improves performance. How Boost.Redis handles batching: Create a request object Push multiple commands into that request using push() Execute the entire batch with a single async_exec() call Receive all responses together in a typed response object

Setting Up Headers and Namespace Aliases

First, we include the necessary headers and create namespace aliases for convenience: C++ #include <boost/redis.hpp> #include <boost/asio/io_context.hpp> #include <boost/asio/detached.hpp> #include <boost/asio/consign.hpp> #include <iostream> #include <string> #include <memory> #include <cstdint> #include <boost/redis/src.hpp> namespace net = boost::asio; using boost::redis::connection; using boost::redis::config; using boost::redis::logger; using boost::redis::request; using boost::redis::response; The key types here are: request : A container where you push multiple commands to batch them together response<Types...> : A typed container that holds the replies for all commands in your batch connection : The Redis client connection that executes your batched requests

Handling the GET Results

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Why `net::consign(net::detached, conn)` is used with `async_run`

connection::async_run(...) starts the connection’s internal asynchronous loop (connecting, reading replies, writing requests, handling reconnects, etc.). Like any async operation in Asio, it takes a completion token that decides how the completion handler is represented and invoked.

net::detached means: start the async operation, but don’t provide a user handler to be called on completion.
In other words, we’re saying “run the connection in the background; I don’t care about the final completion callback.”
Problem: when you use detached, there is no user handler object that naturally “owns” anything. That matters because asynchronous operations must not outlive the objects they use. If the connection were destroyed while async_run is still active, the program could crash (use-after-free) or behave unpredictably.
net::consign(token, value...) solves this by attaching extra objects to the completion handler, ensuring they stay alive until the operation completes.
So net::consign(net::detached, conn) effectively means:

“Run this operation detached, but keep conn alive until async_run finishes.”

In short:

detached removes the callback
consign(..., conn) keeps conn alive anyway, by tying its lifetime to the async operation

This is a common Asio lifetime-management pattern when you intentionally don’t have a completion handler.

C++

int main() {
    try {
        net::io_context ioc;

        auto conn = std::make_shared<connection>(ioc.get_executor());

        config cfg; // Defaults to 127.0.0.1:6379

        // Start the connection's background read/write loop.
        // detached: no user completion callback
        // consign(..., conn): keep conn alive until async_run completes
        conn->async_run(cfg, logger{logger::level::disabled},
                        net::consign(net::detached, conn));

        // BATCH 1: Create a request and push two commands into it
        auto batch_req  = std::make_shared<request>();
        auto batch_resp = std::make_shared<response<std::int64_t, std::string>>();

        // Push commands into the batch
        batch_req->push("INCR", "courses_completed");  // Command 1
        batch_req->push("SET", "user", "John");        // Command 2

        // Execute the entire batch with one async_exec call
        conn->async_exec(*batch_req, *batch_resp,
            [conn, batch_req, batch_resp](boost::system::error_code ec, std::size_t) {
                handle_batch_results(conn, ec, *batch_resp);
            });

        // Run the event loop until all async operations finish
        ioc.run();
    } catch (const std::exception& e) {
        std::cerr << "Exception: " << e.what() << "\n";
        return 1;
    }
    return 0;
}

Here's the batching workflow:

Create a batch: auto batch_req = std::make_shared<request>()
Push commands into the batch:
- batch_req->push("INCR", "courses_completed")
- batch_req->push("SET", "user", "John")
Execute the entire batch at once: conn->async_exec(*batch_req, *batch_resp, ...)
Process all results together: The handler receives responses for all batched commands
Optional: Create and execute another batch: In the handler, we create a second batch with two GET commands

The key insight: Instead of calling async_exec() twice (once for INCR, once for SET), we batch them together and call async_exec() only once. This reduces network round trips from 2 to 1.

Introduction

Understanding Command Batching

Setting Up Headers and Namespace Aliases

Handling the GET Results

Join the 1M+ learners on CodeSignal

Handling the Batch (INCR + SET) Results

Creating the I/O Context, Connection, and Batches

Why `net::consign(net::detached, conn)` is used with `async_run`

What Batching Does and Doesn't Do

Why It Matters