MULTI command to start in Redis - Time & Space Complexity

Time Complexity: MULTI command to start

O(n)

Understanding Time Complexity

We want to understand how the time needed to run Redis commands changes when using the MULTI command to start a transaction.

Specifically, we ask: how does the number of operations grow as we add more commands inside a MULTI block?

Scenario Under Consideration

Analyze the time complexity of the following Redis commands using MULTI.

MULTI
SET key1 value1
SET key2 value2
SET key3 value3
EXEC
    

This code starts a transaction with MULTI, queues three SET commands, then runs them all at once with EXEC.

Identify Repeating Operations

Look for repeated actions inside the transaction.

• Primary operation: Queuing each SET command inside MULTI.
• How many times: Once per command added to the transaction (3 times here).

How Execution Grows With Input

As you add more commands inside MULTI, the number of operations grows roughly the same as the number of commands.

Input Size (n commands)	Approx. Operations
10	About 10 queue operations plus 1 EXEC
100	About 100 queue operations plus 1 EXEC
1000	About 1000 queue operations plus 1 EXEC

Pattern observation: The total work grows linearly with the number of commands queued.

Final Time Complexity

Time Complexity: O(n)

This means the time to queue commands inside MULTI grows in direct proportion to how many commands you add.

Common Mistake

[X] Wrong: "Using MULTI makes all commands run instantly together, so time does not grow with more commands."

[OK] Correct: Even though commands run as a group, Redis still queues each command one by one, so the time to queue grows with the number of commands.

Interview Connect

Understanding how MULTI queues commands helps you explain transaction costs clearly and shows you know how Redis handles grouped commands efficiently but not magically instantly.

Self-Check

"What if we replaced multiple SET commands inside MULTI with a single Lua script? How would the time complexity change?"

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