Key design patterns in Redis - Step-by-Step Execution

Concept Flow - Key design patterns

Start: Choose Data Use Case

↓

Select Pattern Type

↓

Cache

↓

Store Data

↓

Retrieve Fast

↓

End

This flow shows how Redis key design patterns are chosen based on use case, then applied to store, communicate, or control data.

Execution Sample

Redis

SET user:1000 "Alice"
GET user:1000
PUBLISH channel1 "Hello"
INCR rate_limit:1000
EXPIRE rate_limit:1000 60

This example sets and gets a cache key, publishes a message, increments a rate limit counter, and sets its expiration.

Execution Table

Step	Command	Key/Channel	Action	Result/State Change
1	SET	user:1000	Store value 'Alice'	user:1000 = 'Alice'
2	GET	user:1000	Retrieve value	'Alice' returned
3	PUBLISH	channel1	Send message 'Hello'	Message 'Hello' sent to channel1
4	INCR	rate_limit:1000	Increment counter	rate_limit:1000 = 1
5	EXPIRE	rate_limit:1000	Set expiration 60s	rate_limit:1000 expires in 60 seconds
6	GET	rate_limit:1000	Retrieve counter	'1' returned
7	WAIT 61s	-	Wait for expiration	rate_limit:1000 key expired
8	GET	rate_limit:1000	Try retrieve expired key	nil (key not found)

💡 Execution stops after key expiration and retrieval returns nil.

Variable Tracker

Key	Start	After Step 1	After Step 4	After Step 5	After Step 7	Final
user:1000	nil	'Alice'	'Alice'	'Alice'	nil	nil
rate_limit:1000	nil	nil	1	1 (expires in 60s)	expired	nil

Key Moments - 3 Insights

Why does GET return nil at step 8 for rate_limit:1000?

Because at step 7, the key expired after 60 seconds, so it no longer exists in Redis. This is shown in execution_table row 7 and 8.

How does INCR work on a non-existing key at step 4?

INCR creates the key with value 0 before incrementing, so after step 4 the key rate_limit:1000 has value 1, as shown in execution_table row 4.

What is the purpose of EXPIRE in step 5?

EXPIRE sets a time limit on the key, so it will be deleted after 60 seconds, enabling automatic cleanup. This is why the key expires by step 7.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of user:1000 after step 2?

A 'Bob'

B 'Alice'

C nil

D Error

💡 Hint

Check execution_table row 2 under Result/State Change for GET user:1000

At which step does rate_limit:1000 key expire?

A Step 7

B Step 5

C Step 6

D Step 8

💡 Hint

Look at execution_table rows 5, 7, and 8 for expiration and retrieval

If EXPIRE was not called at step 5, what would happen at step 8?

A INCR would fail

B GET would return nil

C GET would return '1'

D PUBLISH would fail

💡 Hint

Refer to variable_tracker for rate_limit:1000 key state after expiration

Concept Snapshot

Redis Key Design Patterns:
- Use SET/GET for caching data.
- Use PUBLISH/SUBSCRIBE for messaging.
- Use INCR + EXPIRE for rate limiting.
- EXPIRE auto-deletes keys after time.
- Keys can store strings, counters, or messages.
- Patterns help organize Redis usage clearly.

Full Transcript

This visual execution trace shows Redis key design patterns by running commands step-by-step. We start by storing a user name with SET, then retrieve it with GET. Next, we publish a message to a channel. Then we increment a rate limit counter and set it to expire in 60 seconds. After waiting, the key expires and GET returns nil. The variable tracker shows how keys change over time. Key moments clarify why keys expire and how INCR works on new keys. The quiz tests understanding of key values at different steps and effects of expiration. This helps beginners see how Redis patterns work in practice.

Practice

1. What is the main purpose of using key design patterns in Redis?

easy

A. To delete all keys automatically

B. To organize data for easy access and management

C. To slow down data retrieval

D. To increase the size of the database

Solution

1. Step 1: Understand Redis key design patterns

   Key design patterns help organize Redis keys logically.

2. Step 2: Identify the main benefit

   Organizing keys makes data easier to access and manage efficiently.

3. Final Answer:

   To organize data for easy access and management -> Option B

4. Quick Check:

   Key design patterns = organize data [OK]

Hint: Think about why organization helps in real life [OK]

Common Mistakes:

• Confusing organization with database size
• Assuming patterns slow down Redis
• Thinking patterns delete keys automatically

2. Which of the following is a correct Redis key pattern to group user data by user ID?

easy

A. user:1234:name

B. user-1234-name

C. user1234name

D. user/1234/name

Solution

1. Step 1: Identify common Redis key pattern syntax

   Redis keys often use colons ':' as separators for readability and grouping.

2. Step 2: Compare options

   user:1234:name uses colons to separate user, ID, and attribute clearly.

3. Final Answer:

   user:1234:name -> Option A

4. Quick Check:

   Colon separators = correct pattern [OK]

Hint: Use colons to separate parts of keys [OK]

Common Mistakes:

• Using dashes or slashes which are less common
• Not separating parts clearly
• Combining all parts without separators

3. Given these Redis keys: order:1001:status, order:1002:status, and order:1001:items, which command retrieves the status of order 1002?

medium

A. GET order:1001:items

B. GET order:1002:items

C. GET order:1002:status

D. GET order:1001:status

Solution

1. Step 1: Identify the key for order 1002 status

   The key format is order:<order_id>:status, so for 1002 it is order:1002:status.

2. Step 2: Match the command to the key

   GET order:1002:status retrieves the status of order 1002.

3. Final Answer:

   GET order:1002:status -> Option C

4. Quick Check:

   Correct key = order:1002:status [OK]

Hint: Match key parts exactly to get correct data [OK]

Common Mistakes:

• Mixing order IDs in keys
• Using wrong attribute like items instead of status
• Confusing similar keys

4. You have keys like session-123 and session:124. Why might this inconsistency cause problems?

medium

A. Redis will merge both keys automatically

B. Redis will throw a syntax error

C. Keys with dashes are not allowed in Redis

D. It breaks pattern consistency, making data harder to manage

Solution

1. Step 1: Understand key pattern consistency

   Consistent key patterns help group and find related data easily.

2. Step 2: Analyze the impact of mixed separators

   Using both dashes and colons breaks this consistency, causing confusion.

3. Final Answer:

   It breaks pattern consistency, making data harder to manage -> Option D

4. Quick Check:

   Inconsistent keys = management issues [OK]

Hint: Always use one separator style consistently [OK]

Common Mistakes:

• Thinking Redis forbids dashes
• Expecting syntax errors from mixed separators
• Assuming Redis merges keys automatically

5. You want to store product reviews in Redis for multiple products and users. Which key design pattern is best to efficiently group reviews by product and user?

hard

A. review:<product_id>:<user_id>

B. <product_id>-review-<user_id>

C. review<product_id><user_id>

D. review/<product_id>/<user_id>

Solution

1. Step 1: Identify clear, scalable key pattern

   Using colons to separate product and user IDs groups reviews logically.

2. Step 2: Evaluate options for clarity and consistency

   review:<product_id>:<user_id> uses colons and a prefix 'review' for easy filtering and management.

3. Final Answer:

   review:<product_id>:<user_id> -> Option A

4. Quick Check:

   Colon-separated keys = best practice [OK]

Hint: Use prefixes and colons to group related data [OK]

Common Mistakes:

• Using ambiguous separators like dashes or slashes
• Combining parts without separators
• Not using a clear prefix for grouping