Redis offers blocking list commands such as BLPOP and BLMOVE. Explain what blocking means here, what happens to the server and to other clients while one client is blocked, and how these commands behave inside a MULTI/EXEC transaction.

## What blocking means A blocking list command is a way to wait for work without polling. Instead of a consumer looping on LPOP with a sleep — which wastes round trips and adds latency equal to the poll interval — the consumer issues BLPOP queue 0 and Redis holds the reply until an element exists. The critical mechanic is that the client blocks, not the server. When Redis cannot satisfy a blocking pop it puts that client into a blocked state, records which keys it is waiting on, and returns to serving other connections. Nothing is stalled globally. When another client pushes to a watched key, Redis wakes waiting clients as part of handling that push. ## The command family - BLPOP key [key ...] timeout and BRPOP: blocking forms of LPOP/RPOP. Multiple keys are checked left to right, so BLPOP high normal low 0 always drains high first. - BLMOVE source destination LEFT|RIGHT LEFT|RIGHT timeout: blocking form of LMOVE, which atomically pops from one list and pushes to another. It replaces BRPOPLPUSH, deprecated in Redis 6.2. - BLMPOP (Redis 7.0): blocking form of LMPOP, popping up to count elements from the first non-empty key. BLPOP's reply is a two-element array of key and value, precisely because you may have supplied many keys and need to know which fired. On timeout you get a nil reply, which client libraries usually surface as null rather than an error. ## Fairness and wake-up order If several clients are blocked on the same key, Redis serves them in the order they blocked: first to wait is first served. A single pushed element therefore wakes exactly one waiter, which is what makes BLPOP a work-distribution primitive rather than a broadcast — each job goes to one consumer. There is a subtlety when a push and a pop happen inside the same atomic unit. If a transaction or script pushes and then does other work, blocked clients are served after the whole unit finishes, not in the middle of it. A push followed by a delete of the same key inside one transaction can leave the waiter unserved, because the element was never observable between commands. ## Inside MULTI/EXEC and scripts Blocking commands cannot block during EXEC. The server executes the queued commands as one atomic step, so waiting would deadlock the instance. Redis therefore runs BLPOP as if it were LPOP: on an empty list the queued command's result is nil and EXEC proceeds. The same rule applies inside Lua scripts and Functions. Candidates who claim BLPOP inside MULTI waits for its timeout are wrong in an instructive way — the reason it cannot is that transaction execution is a single indivisible step. ## Operational notes Blocked clients still hold a connection, so a large consumer fleet means a large connection count; CLIENT LIST shows them and CLIENT UNBLOCK releases one by client id. Because BLPOP mutates a key it carries the write flag, so it must target the primary and fails on a read-only replica. And a blocking pop gives at-most-once delivery: the element is gone the moment the consumer receives it, so a crash mid-processing loses the job — which is exactly why the reliable pattern uses BLMOVE into a processing list instead.