Atomicity, Transactions, and WATCH

What you'll walk away with

Explain the core ideas behind Atomicity, Transactions, and WATCH
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

Each Redis command is atomic. MULTI queues commands and EXEC runs them in order, but Redis does not roll back runtime errors like a SQL transaction. WATCH provides optimistic locking by aborting EXEC when watched keys change; clients need bounded retries.

Connect it to a real scenario

For course-seat reservation, WATCH `seats:course:42`, read and validate capacity, then MULTI, decrement, add an enrollment marker, and EXEC. Under high contention, switch to a short Lua script for fewer round trips and atomic execution.

Single commands are atomic
MULTI/EXEC has no rollback
Retry WATCH aborts with a limit

Try the working example

shell

WATCH seats:course:42
GET seats:course:42
MULTI
DECR seats:course:42
SADD course:42:enrolled user:7
EXEC
UNWATCH

You should see

Both commands commit if the key is unchanged; otherwise EXEC returns a null reply.

5-minute try-it

Write WATCH-and-retry pseudocode for a non-financial inventory reservation.

One important caution

Do not treat Redis EXEC and a PostgreSQL commit as one atomic transaction; use an outbox or another consistency design.

Redis — Transactions — Redis

Easy traps

Do not treat Redis EXEC and a PostgreSQL commit as one atomic transaction; use an outbox or another consistency design.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Write WATCH-and-retry pseudocode for a non-financial inventory reservation.

You'll know it worked when: Both commands commit if the key is unchanged; otherwise EXEC returns a null reply.