Session storage pattern in Redis - Time & Space Complexity

Time Complexity: Session storage pattern

O(1)

Understanding Time Complexity

When storing user sessions in Redis, it is important to understand how the time to save or retrieve a session changes as the number of sessions grows.

We want to know how the cost of session operations grows with more users.

Scenario Under Consideration

Analyze the time complexity of the following Redis commands used for session storage.

# Store session data as a hash
HSET session:1234 user_id 42 last_active 1680000000

# Retrieve session data
HGETALL session:1234

# Delete session when user logs out
DEL session:1234

# Set expiration for session
EXPIRE session:1234 3600

This code stores, retrieves, deletes, and expires a user session using Redis hashes and keys.

Identify Repeating Operations

Look at the main operations that happen repeatedly when managing sessions.

• Primary operation: Accessing a Redis hash for a single session key.
• How many times: Once per session operation (store, retrieve, delete).

How Execution Grows With Input

Each session operation works on one key and its hash fields, so the time depends mostly on the size of that session's data, not the total number of sessions.

Input Size (n)	Approx. Operations
10 sessions	About the same time per session operation
100 sessions	Still about the same time per session operation
1000 sessions	Still about the same time per session operation

Pattern observation: Time per session operation stays roughly constant no matter how many sessions exist.

Final Time Complexity

Time Complexity: O(1)

This means each session operation takes about the same time regardless of how many sessions are stored.

Common Mistake

[X] Wrong: "As the number of sessions grows, retrieving one session will take longer because Redis has to look through all sessions."

[OK] Correct: Redis uses keys to directly access each session, so it does not scan all sessions. Access time stays constant.

Interview Connect

Understanding how Redis handles session storage efficiently shows you know how to design fast, scalable systems that keep user data ready without delay.

Self-Check

"What if we stored all sessions inside one big Redis hash instead of separate keys? How would the time complexity change?"

Practice

1. What is the main purpose of using Redis for session storage?

easy

A. To keep temporary user data during their visit

B. To permanently store user files

C. To perform complex calculations

D. To replace the database for all data

Solution

1. Step 1: Understand session storage concept

   Session storage is used to keep temporary data about a user while they interact with a website or app.

2. Step 2: Identify Redis role in session storage

   Redis is used to store this temporary data quickly and with expiration to remove it after the session ends.

3. Final Answer:

   To keep temporary user data during their visit -> Option A

4. Quick Check:

   Session storage = temporary user data [OK]

Hint: Session storage = temporary user data storage [OK]

Common Mistakes:

• Thinking Redis stores permanent files
• Confusing session storage with database replacement
• Assuming Redis does complex calculations

2. Which Redis command is used to save session data with an expiration time?

easy

A. GET

B. HGETALL

C. DEL

D. SETEX

Solution

1. Step 1: Recall Redis commands for session storage

   GET retrieves data, DEL deletes data, HGETALL gets all hash fields, SETEX sets a key with expiration.

2. Step 2: Identify command to save with expiration

   SETEX is the command that sets a key's value and expiration time in one step.

3. Final Answer:

   SETEX -> Option D

4. Quick Check:

   Save with expiration = SETEX [OK]

Hint: SETEX sets value with expiration in Redis [OK]

Common Mistakes:

• Using GET to save data
• Using DEL to save data
• Confusing HGETALL with setting data

3. Given the commands:
SETEX session:12345 300 "user_data"
GET session:12345
What will be the output of the GET command immediately after SETEX?

medium

A. SyntaxError

B. nil

C. "user_data"

D. 300

Solution

1. Step 1: Understand SETEX effect

   SETEX sets the key 'session:12345' with value 'user_data' and expiration 300 seconds.

2. Step 2: Check GET output immediately after SETEX

   Since the key exists and is not expired yet, GET returns the stored value 'user_data'.

3. Final Answer:

   "user_data" -> Option C

4. Quick Check:

   GET after SETEX returns stored value [OK]

Hint: GET returns value if key exists and not expired [OK]

Common Mistakes:

• Expecting nil immediately after SETEX
• Confusing expiration time with returned value
• Thinking GET returns expiration time

4. What is wrong with this Redis command sequence for session deletion?
DEL session:12345
GET session:12345

medium

A. DEL command syntax is incorrect

B. No error; GET returns nil after DEL

C. GET will still return data after DEL

D. DEL does not delete keys

Solution

1. Step 1: Check DEL command correctness

   DEL session:12345 is correct syntax to delete the key.

2. Step 2: Understand GET after DEL

   After deletion, GET returns nil because the key no longer exists.

3. Final Answer:

   No error; GET returns nil after DEL -> Option B

4. Quick Check:

   DEL deletes key, GET returns nil [OK]

Hint: DEL removes key; GET returns nil after deletion [OK]

Common Mistakes:

• Thinking DEL syntax is wrong
• Expecting GET to return old data after DEL
• Believing DEL does not remove keys

5. You want to store user session data in Redis that expires after 10 minutes. Which sequence correctly sets and later deletes the session?

hard

A. SETEX session:abc 600 "data"; DEL session:abc

B. SET session:abc "data"; DEL session:abc; EXPIRE session:abc 600

C. SET session:abc 600 "data"; EXPIRE session:abc 600; DEL session:abc

D. GET session:abc; SET session:abc 600 "data"; DEL session:abc

Solution

1. Step 1: Identify correct way to set with expiration

   SETEX sets the key with value and expiration in one command, which is efficient and correct.

2. Step 2: Confirm deletion after setting

   DEL removes the key when session ends, so DEL after SETEX is correct.

3. Final Answer:

   SETEX session:abc 600 "data"; DEL session:abc -> Option A

4. Quick Check:

   SETEX sets with expiry, DEL deletes key [OK]

Hint: Use SETEX to set with expiry, then DEL to delete [OK]

Common Mistakes:

• Setting expiration after deleting key
• Using GET before setting session
• Setting expiration separately instead of SETEX