MULTI command to start in Redis - Deep Dive

Overview - MULTI command to start

What is it?

The MULTI command in Redis starts a transaction block. It tells Redis to queue up multiple commands and execute them all at once later. This helps group commands so they run together without interruption. The commands are only run when EXEC is called.

Why it matters

Without MULTI, commands run one by one immediately, which can cause problems if you want several commands to happen together safely. MULTI ensures all commands in a group run as a single unit, preventing partial updates and keeping data consistent. This is important for things like banking or inventory systems.

Where it fits

Before learning MULTI, you should understand basic Redis commands and how Redis works as a key-value store. After MULTI, you can learn about EXEC, DISCARD, and WATCH commands to manage transactions fully.

Mental Model

Core Idea

MULTI marks the start of a group of commands that Redis will run together later as one atomic transaction.

Think of it like...

Think of MULTI like putting several letters into an envelope before mailing them all at once. You prepare everything first, then send them together so they arrive together.

┌─────────────┐
│ MULTI (start)│
└─────┬───────┘
      │
┌─────▼───────┐
│ Commands queued │
│ (SET, INCR, etc)│
└─────┬───────┘
      │
┌─────▼───────┐
│ EXEC (run all)│
└─────────────┘

Build-Up - 7 Steps

1

Foundation

What is Redis and Commands

Concept: Redis stores data as keys and values and lets you run commands to read or change data.

Redis is like a fast dictionary where you can add, get, or change values using commands like SET and GET. Each command runs immediately and changes the data right away.

Result

You can store and retrieve data quickly with simple commands.

Understanding how Redis commands work individually sets the stage for grouping them with MULTI.

2

Foundation

Why Group Commands Together

Concept: Sometimes you want several commands to happen together so data stays correct and consistent.

Imagine you want to move money from one account to another. You need to subtract from one and add to another. If something interrupts between these commands, data breaks. Grouping commands solves this.

Result

You see the need for running commands as a single unit to avoid partial changes.

Knowing the problem MULTI solves helps you appreciate why transactions matter.

3

Intermediate

Starting a Transaction with MULTI

🤔Before reading on: do you think MULTI runs commands immediately or queues them? Commit to your answer.

Concept: MULTI tells Redis to stop running commands right away and queue them instead.

When you send MULTI, Redis replies OK and waits. The next commands you send are not executed but stored in a list. They only run when you send EXEC.

Result

Commands after MULTI are queued, not run, until EXEC.

Understanding that MULTI queues commands changes how you think about command execution timing.

4

Intermediate

Executing Queued Commands with EXEC

🤔Before reading on: do you think EXEC runs commands one by one or all at once atomically? Commit to your answer.

Concept: EXEC runs all queued commands together as one atomic operation.

After MULTI queues commands, EXEC tells Redis to run them all in order without interruption. If any command fails, others still run, but the whole block is treated as a single unit.

Result

All queued commands run together, ensuring data consistency.

Knowing EXEC runs commands atomically helps prevent partial updates in your data.

5

Intermediate

Cancelling a Transaction with DISCARD

Concept: You can cancel queued commands before running them using DISCARD.

If you decide not to run the queued commands, sending DISCARD clears the queue and ends the transaction. Redis replies OK and returns to normal command mode.

Result

Queued commands are removed and not executed.

Knowing how to cancel transactions safely prevents unwanted changes.

6

Advanced

Error Handling Inside Transactions

🤔Before reading on: do you think Redis stops all commands if one queued command is invalid? Commit to your answer.

Concept: Redis queues commands without checking errors until EXEC runs them all.

If a command is invalid, Redis still queues it. Only when EXEC runs does Redis report errors for specific commands but still runs others. This means partial failures can happen inside a transaction.

Result

Some commands may fail during EXEC, but others still run.

Understanding this prevents surprises when errors appear only after EXEC.

7

Expert

WATCH and Optimistic Locking with MULTI

🤔Before reading on: do you think MULTI alone prevents data changes by others during your transaction? Commit to your answer.

Concept: WATCH lets you monitor keys for changes to abort transactions if data changes unexpectedly.

Before MULTI, you can WATCH keys. If any watched key changes before EXEC, Redis aborts the transaction to avoid conflicts. This is optimistic locking to keep data safe in concurrent environments.

Result

Transactions abort if watched keys change, preventing inconsistent updates.

Knowing how WATCH works with MULTI helps build safe concurrent applications.

Under the Hood

When you send MULTI, Redis switches to a special mode where it queues commands in memory instead of running them. These commands are stored in a list. When EXEC arrives, Redis runs all commands sequentially in a single step without other commands interrupting. This atomic execution ensures no other client can run commands in between. If DISCARD is sent, the queue clears and Redis returns to normal mode.

Why designed this way?

Redis was designed for speed and simplicity. MULTI queues commands to avoid complex locking mechanisms. This design keeps transactions fast and lightweight. Alternatives like locking would slow Redis down and complicate its single-threaded model. The queue approach fits Redis's event loop and single-threaded architecture perfectly.

┌─────────────┐
│ Client sends│
│ MULTI      │
└─────┬───────┘
      │
┌─────▼───────┐
│ Redis queues │
│ commands in │
│ memory list │
└─────┬───────┘
      │
┌─────▼───────┐
│ Client sends│
│ EXEC        │
└─────┬───────┘
      │
┌─────▼───────┐
│ Redis runs  │
│ all commands│
│ atomically  │
└─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does MULTI run commands immediately or queue them? Commit to your answer.

Common Belief: MULTI runs commands immediately but marks them as part of a transaction.

Reality: MULTI queues commands without running them until EXEC is called.

Why it matters: Thinking commands run immediately leads to confusion about when data changes happen and can cause bugs in transaction logic.

Quick: If one command in a MULTI block fails, does Redis cancel all commands? Commit to your answer.

Common Belief: If one command fails, Redis cancels the entire transaction.

Reality: Redis still runs all commands; errors are reported after EXEC but do not stop other commands.

Why it matters: Assuming full rollback can cause data inconsistency if you don't check for errors after EXEC.

Quick: Does MULTI prevent other clients from changing data during your transaction? Commit to your answer.

Common Belief: MULTI locks keys so no other client can change data until EXEC finishes.

Reality: MULTI alone does not lock keys; other clients can change data unless you use WATCH.

Why it matters: Believing MULTI locks data can lead to race conditions and unexpected overwrites.

Quick: Can you run commands outside MULTI after sending MULTI but before EXEC? Commit to your answer.

Common Belief: You can run normal commands anytime even after MULTI starts.

Reality: After MULTI, commands are queued and not executed until EXEC or DISCARD ends the transaction.

Why it matters: Trying to run commands outside the transaction causes confusion and errors.

Expert Zone

1

Redis transactions are not fully isolated; commands run atomically but intermediate states are visible to other clients.

2

Errors inside EXEC do not rollback previous commands; you must handle errors manually after EXEC.

3

WATCH uses optimistic locking, which is efficient but requires retry logic in client code for conflicts.

When NOT to use

MULTI is not suitable when you need full rollback on errors or strict isolation. In such cases, use external locking or databases with full ACID transactions like PostgreSQL.

Production Patterns

In production, MULTI is combined with WATCH for safe concurrency. Clients often retry transactions on WATCH failures. MULTI is used for atomic counters, inventory updates, and session management where speed and atomicity matter.

Connections

Database Transactions

MULTI is Redis's way to implement transactions similar to other databases.

Understanding traditional database transactions helps grasp why MULTI queues commands and uses EXEC to commit.

Optimistic Locking

WATCH with MULTI implements optimistic locking to handle concurrent changes.

Knowing optimistic locking from other systems clarifies how Redis avoids heavy locks while keeping data safe.

Event Loop Programming

Redis's single-threaded event loop design influences how MULTI queues commands.

Understanding event loops explains why Redis queues commands instead of locking, keeping performance high.

Common Pitfalls

#1 Expecting commands to run immediately after MULTI.

Wrong approach:

MULTI
SET key1 value1
GET key1

Correct approach:

MULTI
SET key1 value1
GET key1
EXEC

Root cause:

Misunderstanding that MULTI queues commands and requires EXEC to run them.

#2 Assuming all commands rollback if one fails inside EXEC.

Wrong approach:

MULTI
SET key1 value1
INVALIDCOMMAND
EXEC

Correct approach:

MULTI
SET key1 value1
INVALIDCOMMAND
EXEC
// Check EXEC result for errors and handle manually

Root cause:

Belief that Redis transactions have full rollback like traditional databases.

#3 Not using WATCH when concurrent changes matter.

Wrong approach:

MULTI
INCR counter
EXEC

Correct approach:

WATCH counter
MULTI
INCR counter
EXEC

Root cause:

Ignoring that MULTI alone does not prevent race conditions.

Key Takeaways

MULTI starts a transaction by queuing commands instead of running them immediately.

EXEC runs all queued commands atomically, ensuring they execute together without interruption.

Errors inside a transaction do not rollback previous commands; you must check EXEC results carefully.

WATCH combined with MULTI provides optimistic locking to handle concurrent data changes safely.

Understanding Redis's single-threaded design explains why MULTI queues commands rather than locking keys.

Practice

1.

What does the MULTI command do in Redis?

easy

A. Immediately executes all commands

B. Starts a transaction block to queue commands

C. Deletes all keys in the database

D. Shows the current database size

Solution

1. Step 1: Understand the purpose of MULTI

   The MULTI command begins a transaction block where commands are queued instead of executed immediately.

2. Step 2: Compare with other options

   The other options describe different Redis commands or actions unrelated to MULTI.

3. Final Answer:

   Starts a transaction block to queue commands -> Option B

4. Quick Check:

   MULTI = start transaction block [OK]

Hint: MULTI queues commands for atomic execution [OK]

Common Mistakes:

• Thinking MULTI executes commands immediately
• Confusing MULTI with FLUSHDB or DBSIZE
• Assuming MULTI deletes keys

2.

Which of the following is the correct syntax to start a transaction block in Redis?

?

easy

A. START TRANSACTION

B. EXEC

C. MULTI

D. BEGIN

Solution

1. Step 1: Identify Redis transaction start command

   In Redis, MULTI is used to start a transaction block.

2. Step 2: Check other options

   EXEC runs queued commands, BEGIN and START TRANSACTION are SQL commands, not Redis.

3. Final Answer:

   MULTI -> Option C

4. Quick Check:

   Start transaction = MULTI [OK]

Hint: MULTI starts, EXEC runs queued commands [OK]

Common Mistakes:

• Using SQL syntax like BEGIN or START TRANSACTION
• Confusing EXEC as start command
• Typing lowercase commands (Redis commands are case-insensitive but usually uppercase)

3.

Consider the following Redis commands executed in order:

MULTI
SET key1 value1
SET key2 value2
EXEC
GET key1
GET key2

What will be the output of the two GET commands?

medium

A. ["value1", "value2"]

B. [null, null]

C. ["value1", null]

D. [null, "value2"]

Solution

1. Step 1: Understand MULTI and EXEC behavior

   The commands between MULTI and EXEC are queued and executed atomically when EXEC runs. So both SET commands run together.

2. Step 2: Check GET commands after EXEC

   After EXEC, both keys are set, so GET key1 returns "value1" and GET key2 returns "value2".

3. Final Answer:

   ["value1", "value2"] -> Option A

4. Quick Check:

   Queued SETs run on EXEC, GET returns set values [OK]

Hint: EXEC runs queued commands, so GET sees updated keys [OK]

Common Mistakes:

• Assuming SET commands run immediately before EXEC
• Expecting null because commands are queued
• Confusing output format of GET commands

4.

What is wrong with this Redis transaction block?

MULTI
SET key1 value1
GET key1
EXEC

medium

A. MULTI must be followed by WATCH

B. EXEC must come before GET

C. SET cannot be used inside MULTI

D. GET inside MULTI queues the command, does not return value immediately

Solution

1. Step 1: Analyze GET inside MULTI block

   Inside MULTI, commands are queued and do not return results immediately, so GET queues but does not return the value now.

2. Step 2: Understand EXEC behavior

   EXEC runs all queued commands and returns their results together, so GET's result is only available after EXEC.

3. Final Answer:

   GET inside MULTI queues the command, does not return value immediately -> Option D

4. Quick Check:

   Commands queue inside MULTI, results after EXEC [OK]

Hint: GET inside MULTI queues, no immediate output [OK]

Common Mistakes:

• Expecting GET to return value immediately inside MULTI
• Thinking EXEC must come before GET
• Believing SET is disallowed inside MULTI

5.

You want to update two keys user:1 and user:2 atomically in Redis. Which sequence correctly uses MULTI and EXEC to ensure both updates happen together?

?

hard

A. MULTI
SET user:1 "Alice"
SET user:2 "Bob"
EXEC

B. SET user:1 "Alice"
MULTI
SET user:2 "Bob"
EXEC

C. MULTI
SET user:1 "Alice"
EXEC
SET user:2 "Bob"

D. EXEC
MULTI
SET user:1 "Alice"
SET user:2 "Bob"

Solution

1. Step 1: Identify correct transaction block

   MULTI SET user:1 "Alice" SET user:2 "Bob" EXEC starts with MULTI, queues both SET commands, then runs them together with EXEC.

2. Step 2: Check other options for errors

   SET user:1 "Alice" MULTI SET user:2 "Bob" EXEC queues only one SET inside MULTI; MULTI SET user:1 "Alice" EXEC SET user:2 "Bob" runs EXEC too early; EXEC MULTI SET user:1 "Alice" SET user:2 "Bob" starts with EXEC which is invalid.

3. Final Answer:

   MULTI SET user:1 "Alice" SET user:2 "Bob" EXEC -> Option A

4. Quick Check:

   Queue all commands between MULTI and EXEC [OK]

Hint: Queue all commands between MULTI and EXEC for atomic update [OK]

Common Mistakes:

• Calling EXEC before queuing all commands
• Starting EXEC before MULTI
• Mixing commands outside transaction block