Why MULTI command to start in Redis? - Purpose & Use Cases

The Big Idea

What if you could guarantee that a group of commands either all succeed or none do, avoiding messy partial updates?

The Scenario

Imagine you are trying to update several pieces of data in a database one by one, like paying multiple bills separately. You have to make sure each payment goes through without errors, and if one fails, you want to stop and fix it before continuing.

The Problem

Doing this manually means you might accidentally pay some bills twice or miss some payments if something goes wrong halfway. It's slow and risky because you have to check each step carefully and handle errors yourself.

The Solution

The MULTI command in Redis lets you group several commands together as a single unit. This way, either all commands run successfully, or none do. It's like putting all your bills in one envelope and sending them at once, so you know they all get processed together.

Before vs After

✗ Before

SET key1 value1
INCR counter
DEL key2

✓ After

MULTI
SET key1 value1
INCR counter
DEL key2
EXEC

What It Enables

This makes your data updates safe and consistent, preventing partial changes that can cause confusion or errors.

Real Life Example

For example, when transferring money between two bank accounts, you want to debit one account and credit another at the same time. Using MULTI ensures both actions happen together or not at all.

Key Takeaways

MULTI groups commands to run as one transaction.

It prevents partial updates and keeps data consistent.

It simplifies error handling and improves reliability.

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