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.