Redis as cache vs data store vs message broker - Performance Comparison

Time Complexity: Redis as cache vs data store vs message broker

O(1) for cache SET/GET, O(log n) for sorted set add, O(m) for sorted set range, O(s) for publish

Understanding Time Complexity

When using Redis in different roles like cache, data store, or message broker, it's important to understand how the time it takes to do tasks changes as the amount of data or messages grows.

We want to see how Redis handles more data or messages in each role.

Scenario Under Consideration

Analyze the time complexity of these Redis commands in different roles.

# Cache: Set and Get operations
SET user:1 "Alice"
GET user:1

# Data Store: Sorted Set add and range query
ZADD leaderboard 100 "player1"
ZRANGE leaderboard 0 9 WITHSCORES

# Message Broker: Publish and Subscribe
PUBLISH channel1 "Hello"
SUBSCRIBE channel1
    

This code shows basic commands for Redis as a cache, data store, and message broker.

Identify Repeating Operations

• Primary operation: Each command like SET, GET, ZADD, ZRANGE, PUBLISH, SUBSCRIBE.
• How many times: These commands run once per request, but many requests happen over time.
• For ZRANGE, the number of items requested affects how much work Redis does.
• For PUBLISH, Redis sends messages to all subscribers, so work grows with subscriber count.

How Execution Grows With Input

Let's see how work grows when we increase data or messages.

Input Size (n)	Approx. Operations
10	About 10 commands, small data sets, few subscribers
100	About 100 commands, larger sorted sets, more subscribers
1000	About 1000 commands, big sorted sets, many subscribers

Pattern observation: For simple SET/GET, work grows linearly with requests. For sorted sets, work depends on how many items you ask for. For publish, work grows with number of subscribers.

Final Time Complexity

Time Complexity: O(1) for cache SET/GET, O(log n) for sorted set add, O(m) for sorted set range of m items, O(s) for publish with s subscribers

This means simple cache commands take the same time no matter data size, sorted sets take a bit more time as data grows, and publishing messages takes more time as subscribers increase.

Common Mistake

[X] Wrong: "All Redis commands take the same time no matter what."

[OK] Correct: Some commands like SET and GET are very fast and steady, but others like range queries or publishing messages depend on how much data or how many subscribers there are.

Interview Connect

Understanding how Redis handles different tasks helps you explain your choices clearly and shows you know how systems work as they grow. This skill is useful anytime you design or talk about fast data handling.

Self-Check

"What if we changed the number of subscribers in the message broker role? How would the time complexity of PUBLISH change?"

Practice

1. Which of the following best describes Redis when used as a cache?

easy

A. It sends messages between different parts of an app.

B. It permanently stores large amounts of data for apps.

C. It temporarily stores data to speed up app responses.

D. It analyzes data to find patterns automatically.

Solution

1. Step 1: Understand Redis cache role

   Redis cache stores data temporarily to help apps respond faster by avoiding repeated data fetching.

2. Step 2: Compare other roles

   Permanent storage is data store, messaging is message broker, and analysis is not Redis's main role.

3. Final Answer:

   It temporarily stores data to speed up app responses. -> Option C

4. Quick Check:

   Cache = Temporary fast storage [OK]

Hint: Cache means temporary fast storage to speed apps [OK]

Common Mistakes:

• Confusing cache with permanent data store
• Thinking Redis analyzes data automatically
• Mixing message broker role with cache

2. Which Redis command is used to publish a message to a channel when Redis acts as a message broker?

easy

A. SET

B. PUBLISH

C. GET

D. SUBSCRIBE

Solution

1. Step 1: Identify publish command in Redis

   The PUBLISH command sends a message to subscribers on a channel in Redis's message broker role.

2. Step 2: Differentiate from other commands

   SET stores data, GET retrieves data, SUBSCRIBE listens to messages but does not send them.

3. Final Answer:

   PUBLISH -> Option B

4. Quick Check:

   Send message = PUBLISH [OK]

Hint: Publish sends messages; subscribe listens [OK]

Common Mistakes:

• Using SET or GET to send messages
• Confusing SUBSCRIBE with PUBLISH
• Thinking GET publishes messages

3. Consider this Redis usage: You store user session data with expiration times to speed up login checks. What role is Redis playing here?

medium

A. Cache

B. Message broker

C. Data store

D. Analytics engine

Solution

1. Step 1: Analyze session data with expiration

   Storing data with expiration to speed up access fits caching, as data is temporary and speeds up app.

2. Step 2: Exclude other roles

   Message broker sends messages, data store keeps permanent data, analytics engine is unrelated.

3. Final Answer:

   Cache -> Option A

4. Quick Check:

   Temporary session data = Cache [OK]

Hint: Temporary data with expiry means cache [OK]

Common Mistakes:

• Thinking session data is permanent storage
• Confusing message broker with cache
• Assuming analytics role for session data

4. You wrote this Redis command to send a message: SUBSCRIBE news. What is wrong if your goal was to send a message?

medium

A. SUBSCRIBE deletes the channel.

B. SUBSCRIBE command syntax is incorrect.

C. SUBSCRIBE stores messages permanently.

D. SUBSCRIBE is for receiving messages, not sending.

Solution

1. Step 1: Understand SUBSCRIBE command purpose

   SUBSCRIBE listens to messages on a channel; it does not send messages.

2. Step 2: Identify correct sending command

   To send messages, use PUBLISH, not SUBSCRIBE.

3. Final Answer:

   SUBSCRIBE is for receiving messages, not sending. -> Option D

4. Quick Check:

   SUBSCRIBE = receive, PUBLISH = send [OK]

Hint: Subscribe listens; publish sends messages [OK]

Common Mistakes:

• Using SUBSCRIBE to send messages
• Thinking SUBSCRIBE deletes channels
• Believing SUBSCRIBE stores messages

5. You want to use Redis to both speed up data access and send notifications between app parts. Which setup correctly uses Redis roles?

hard

A. Use Redis as a cache for data and use PUBLISH/SUBSCRIBE for messaging.

B. Use Redis only as a data store and ignore messaging features.

C. Use Redis as a message broker only, not for caching.

D. Use Redis to permanently store messages and cache data simultaneously.

Solution

1. Step 1: Identify Redis roles for caching and messaging

   Redis can cache data to speed access and use PUBLISH/SUBSCRIBE commands to send messages between app parts.

2. Step 2: Exclude incorrect setups

   Ignoring messaging misses notification need; message broker only misses caching; permanent message storage is not typical.

3. Final Answer:

   Use Redis as a cache for data and use PUBLISH/SUBSCRIBE for messaging. -> Option A

4. Quick Check:

   Cache + Pub/Sub = correct multi-role use [OK]

Hint: Combine cache and pub/sub for speed and messaging [OK]

Common Mistakes:

• Using Redis only for one role when multiple needed
• Trying to store messages permanently in Redis
• Ignoring pub/sub for notifications