Understanding Redis Transactions: Principles and Practical Examples

Introduction

A reader recently reported being asked about Redis transactions during an interview, which caused discomfort because they had not studied this feature. Although the interview was passed, the salary was not ideal. This article provides a comprehensive explanation of Redis transactions, from concepts to implementation, to prepare readers for future interview questions.

Transaction Overview

Redis transactions are a group of commands that are queued and executed sequentially. Unlike relational databases, Redis does not provide isolation levels or automatic rollback, which aligns with its design goal of high performance. The transaction lifecycle consists of three steps: START (MULTI) , QUEUE COMMANDS , and EXECUTE (EXEC) or DISCARD (DISCARD) .

The relevant commands are summarized in the table below:

Command

Description

MULTI

Begins a transaction; subsequent commands are queued.

DISCARD

Abandons the queued commands, similar to a rollback.

EXEC

Executes all queued commands in FIFO order; if any watched key changed, the transaction aborts.

WATCH key

Monitors one or more keys before MULTI; if a watched key is modified, EXEC will fail.

UNWATCH

Stops monitoring previously watched keys.

Starting a Transaction

The MULTI command switches the client state to REDIS_MULTI. The server replies OK, indicating that subsequent commands will be queued.

redis> MULTI
OK

Command Queueing

While in transaction mode, each command returns QUEUED and is stored in a FIFO queue. Non‑transactional commands are executed immediately.

redis> SET name "Alice"
QUEUED
redis> GET name
QUEUED

The queue stores the command name, its arguments, and the argument count. For the example above:

Command

Arguments

Argument Count

SET

["name", "Alice"]

2

GET

["name"]

1

Executing a Transaction

When EXEC is issued, the queued commands are executed in order. Successful commands return their normal replies; the transaction then ends and the client state returns to non‑transactional.

redis> EXEC
1) OK
2) "Alice"

If DISCARD is used, the queue is cleared and the transaction is aborted.

redis> DISCARD
OK

WATCH Command

WATCH

must be called before MULTI. It implements an optimistic‑lock mechanism: if any watched key is modified by another client before EXEC, the transaction fails with a (nil) reply.

redis> WATCH counter
OK
redis> MULTI
OK
redis> INCRBY counter 10
QUEUED
redis> DECRBY counter 1
QUEUED
redis> EXEC
1) (integer) 11
2) (integer) 10

If another client changes counter between WATCH and EXEC, the server returns (nil) and aborts the transaction.

Error Handling

Redis distinguishes between syntax errors (detected at command parsing) and runtime errors (detected during execution). A syntax error aborts the entire transaction with EXECABORT. Runtime errors affect only the offending command; other queued commands may still succeed.

# Syntax error example
redis> MULTI
OK
redis> SET key
(error) ERR wrong number of arguments for 'set' command
redis> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

# Runtime error example
redis> MULTI
OK
redis> SET num 3
QUEUED
redis> SADD num 4
QUEUED
redis> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

Redis vs. MySQL Transactions

MySQL provides ACID guarantees (Atomicity, Consistency, Isolation, Durability). Redis sacrifices atomicity and isolation for speed: it does not roll back on errors, does not lock keys, and only guarantees atomicity of single commands. Developers must handle consistency and rollback logic at the application level.

Conclusion

Redis transactions are simple, high‑performance command batches without traditional rollback or isolation. Understanding the command flow, WATCH semantics, and error handling enables developers to use Redis transactions effectively while being aware of their limitations compared to relational databases.