F-7 — Pipelining and the RESP Protocol

Handling Errors in a Pipeline

Each command in a pipeline has its own result slot. An error in one command does not abort the pipeline — it is reported as an error in that slot's [error, result] pair:

const pipeline = redis.pipeline();
pipeline.set('key1', 'value1');
pipeline.lpush('key1', 'will-fail');  // type error: key1 is a String, not a List
pipeline.set('key3', 'value3');
 
const results = await pipeline.exec();
// [
//   [null, 'OK'],
//   [ReplyError: WRONGTYPE Operation against a key..., null],
//   [null, 'OK']
// ]

Unlike transactions (covered in P-5), a pipeline error does not roll back other commands.

---

MGET and MSET: Built-in Batching

For the specific case of getting or setting multiple String keys, Redis provides MGET and MSET as atomic multi-key commands:

MGET key1 key2 key3   → returns array of values in order
MSET key1 v1 key2 v2 key3 v3   → sets all keys atomically

These send a single command (not a pipeline) and are slightly more efficient than a pipeline for pure String batches because there is only one command to parse. But they only work for String keys — for Hashes, Lists, or mixed types, you need pipelining.

// MGET for bulk String reads
const values = await redis.mget('user:1', 'user:2', 'user:3');
// ["value1", "value2", null]  ← null for missing keys
 
// MSET for bulk String writes
await redis.mset('key1', 'val1', 'key2', 'val2', 'key3', 'val3');

---

Pipeline Size: How Many Commands to Batch

There is no fixed "correct" pipeline size. Larger pipelines reduce RTT cost but increase:

• Memory for queued commands on the client side
• Memory for pending responses on the Redis server side
• Time before you can start processing results (you wait for the whole pipeline to finish)

Practical guidelines:

• Small pipelines (10–100 commands): Fine for most operations — enrichment, batch reads, fan-out writes.
• Medium pipelines (100–1,000 commands): The sweet spot for bulk data operations.
• Large pipelines (1,000+ commands): Break into chunks. Sending 100,000 commands at once can overwhelm Redis's output buffer and cause latency spikes for other clients.

// Chunk large batches
async function batchGet(keys: string[], chunkSize = 500) {
  const results: (string | null)[] = [];
  for (let i = 0; i < keys.length; i += chunkSize) {
    const chunk = keys.slice(i, i + chunkSize);
    const pipe = redis.pipeline();
    chunk.forEach(key => pipe.get(key));
    const chunkResults = await pipe.exec();
    results.push(...chunkResults!.map(([, val]) => val as string | null));
  }
  return results;
}

---

Pipelining vs Transactions vs Lua Scripts

These three are often confused because they all involve "sending multiple commands." Here is the distinction:

Pipelining is not atomic. Two pipelines from different clients can interleave. If you need the commands to execute without any other client's commands interleaving, use a transaction (MULTI/EXEC, covered in P-5) or a Lua script (covered in A-2).

---

Connection Pooling and Pipelining Together

A common misconception: "pipelining replaces connection pooling." It does not. They solve different problems.

• Connection pooling — keeps multiple TCP connections open so multiple coroutines/threads can issue commands concurrently without waiting for a shared connection.
• Pipelining — reduces RTT for sequential operations within a single connection.

In a Node.js application with ioredis:

// ioredis automatically pipelines commands issued concurrently via Promise.all
// This is called "auto-pipelining"
const [user, session, config] = await Promise.all([
  redis.get('user:1001'),
  redis.get('session:abc123'),
  redis.hgetall('config:global'),
]);

ioredis's auto-pipelining batches commands that are issued in the same event loop tick into a single network write. You often get pipelining benefits without manually creating a pipeline — but explicit pipelines give you more control over batch size and error handling.

---

Monitoring Pipeline Performance

INFO commandstats

Shows per-command call counts and aggregate microseconds:

cmdstat_get:calls=18432,usec=92160,usec_per_call=5.00
cmdstat_pipeline:calls=142,usec=284000,usec_per_call=2000.00

A high usec_per_call on individual commands with high call counts is the signal that you have sequential loops that should be pipelined.

SLOWLOG GET 10

Shows commands that took longer than slowlog-log-slower-than microseconds (default 10,000 = 10ms). Pipelines themselves are rarely the bottleneck — they appear as fast in the slow log because Redis processes each command quickly. What you want to avoid is many slow sequential single commands.

---

Summary

• Every Redis command pays a network RTT — typically 0.5–2ms on cloud infrastructure
• Sequential loops of await redis.get(key) pay N × RTT for N keys — often the biggest Redis performance mistake
• Pipelining sends multiple commands in one network write, paying RTT once instead of N times
• redis.pipeline() in ioredis: queue commands, then exec() to send all at once
• Each pipeline command has its own result — errors in one command do not abort others
• For pure String batches: MGET / MSET are atomic single-command alternatives
• Optimal pipeline size: 100–1,000 commands; chunk larger batches to avoid output buffer pressure
• Pipelining ≠ atomic — for atomic multi-command operations use transactions or Lua scripts
• ioredis auto-pipelining batches concurrent Promise.all commands automatically

Next: F-8 — Pub/Sub and the Message Fanout Model — where we cover Redis's publish-subscribe system, how it differs from Streams, when to use it, and its most important limitation: messages are fire-and-forget.

---