Transactions

7 questions found

What is a Redis transaction, and how do the MULTI and EXEC commands work together to create one?

Beginner
A Redis transaction lets you group a series of commands together so they are executed sequentially and atomically as a single unit, starting the group with MULTI, queuing each command that follows, and finally running them all at once with EXEC, ensuring no other client's commands can be interleaved in the middle of your sequence.
MULTI
SET account:1:balance 500
DECRBY account:1:balance 100
EXEC
Real-world example A banking application uses a transaction to update two related account balances together, guaranteeing that both updates happen as one uninterrupted operation from the perspective of every other client.

Common follow-ups: What happens if one command inside a transaction fails while it is being queued?;Can you cancel a transaction before calling EXEC?

Distributed Locks with Redis;Lua Scripting

How do you cancel a queued Redis transaction before it executes, and what command is used for this?

Beginner
You use the DISCARD command, which cancels the current transaction and clears all commands that were queued after MULTI was called, returning the connection to its normal state without executing any of the queued commands.
MULTI
SET temp_key 'value'
DISCARD
Real-world example An application starts building a transaction but decides midway through, based on some application logic, that the operation should not proceed, so it calls DISCARD to safely cancel everything queued so far.

Common follow-ups: Does DISCARD affect commands that were already executed outside the transaction?;What is the difference between DISCARD and simply not calling EXEC?

Lua Scripting;Distributed Locks with Redis

How does the WATCH command enable optimistic locking within a Redis transaction?

Intermediate
WATCH lets you monitor one or more keys for changes made by other clients before your transaction executes, and if any watched key is modified between calling WATCH and calling EXEC, the entire transaction is automatically aborted, letting your application detect the conflict and retry the operation safely rather than working with stale data.
WATCH account:1:balance
val = GET account:1:balance
MULTI
SET account:1:balance <new_value>
EXEC
Real-world example An inventory management system watches a product's stock count before decrementing it, so if another customer's purchase changes the stock count first, the transaction safely aborts and the application retries with the updated value.

Common follow-ups: What does EXEC return if a watched key was modified before it ran?;How many keys can be watched at the same time?

Distributed Locks with Redis;Rate Limiting with Redis

What does it mean for Redis transactions to lack full rollback support, and how does this differ from transactions in a traditional relational database?

Intermediate
Unlike a relational database, Redis does not roll back earlier successful commands within a transaction if a later command in the same transaction fails at runtime, since Redis treats runtime errors as isolated to that specific command, meaning your application must be designed with this behavior in mind rather than assuming automatic rollback protection.
MULTI
SET key1 'value1'
INCR key1  -- fails at runtime since key1 is not an integer
EXEC        -- key1 'value1' remains set, only INCR fails
Real-world example A developer migrating from a relational database learns that a Redis transaction will still keep an earlier successful SET command even if a later command in the same transaction fails, and adjusts the application logic accordingly.

Common follow-ups: What is the difference between a queuing time error and a runtime error inside a transaction?;How should an application handle a partial failure within a Redis transaction?

Lua Scripting;Redis Architecture & Installation

When would you choose a Lua script over a MULTI and EXEC transaction to achieve atomicity in Redis?

Advanced
A Lua script is often a better choice when your atomic operation needs conditional logic based on values read partway through, since the entire script runs as a single atomic unit on the server with full access to intermediate results, whereas a plain transaction only queues commands blindly without letting you branch based on values retrieved earlier in the same transaction.
EVAL "local val = redis.call('GET', KEYS[1]) if val == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 mykey expected_value
Real-world example A distributed locking system uses a Lua script instead of a plain transaction to atomically check that a lock's value matches the expected owner before deleting it, something a simple MULTI and EXEC sequence cannot express.

Common follow-ups: What are the performance differences between Lua scripts and transactions for simple use cases?;Can a Lua script call WATCH internally?

Lua Scripting;Distributed Locks with Redis

How do Redis transactions interact with Redis Cluster when the queued commands involve keys located on different shards?

Advanced
In Redis Cluster, all keys accessed within a single transaction must map to the same hash slot, meaning they typically need to reside on the same shard, so applications commonly use hash tags in key names to force related keys into the same slot, ensuring the transaction can execute successfully across a sharded cluster.
MULTI
SET '{user:1000}:profile' 'data'
SET '{user:1000}:settings' 'data'
EXEC
Real-world example A multi tenant application uses hash tags in its key naming scheme so that all keys belonging to the same customer land on the same cluster shard, allowing transactions involving multiple related keys for that customer to execute successfully.

Common follow-ups: What error does Redis return if a transaction spans multiple hash slots?;How do hash tags affect the overall distribution of keys across the cluster?

Cluster Sharding & Hash Slots;Clustering

What is a practical real world example where a Redis transaction ensures data consistency across multiple related keys?

Intermediate
A ticket booking system can use a transaction to simultaneously decrement the available seat count and add the buyer's reservation record, ensuring that both changes are applied together so the seat count never gets out of sync with the actual list of reservations, even under high concurrent booking load.
MULTI
DECR event:5000:available_seats
SADD event:5000:reservations 'user789'
EXEC
Real-world example An online ticketing platform relies on a Redis transaction during checkout to atomically reduce the seat count and record the new reservation, preventing overselling even when many users are booking seats for the same popular event at once.

Common follow-ups: What happens if the available seat count would go negative as a result of this transaction?;Should this be combined with WATCH to prevent overselling under heavy concurrency?

Distributed Locks with Redis;Rate Limiting with Redis