Embedding vs referencing in Redis - Visual Side-by-Side Comparison

Concept Flow - Embedding vs referencing

Start: Need to store related data

↓

Embed data

↓

Store all

↓

inside one

↓

record

↓

Fast read

↓

Use case depends on needs

↓

End

This flow shows the choice between embedding related data inside one record or referencing it by storing IDs separately, highlighting trade-offs.

Execution Sample

Redis

HMSET user:1 name "Alice" age 30
HMSET user:1:address city "NY" zip "10001"
HGETALL user:1
HGETALL user:1:address

Stores user data and address separately (referencing), then retrieves both.

Execution Table

Step	Command	Action	Data Stored/Retrieved	Notes
1	HMSET user:1 name "Alice" age 30	Store user basic info	{"name":"Alice","age":"30"}	User hash created
2	HMSET user:1:address city "NY" zip "10001"	Store address separately	{"city":"NY","zip":"10001"}	Address hash created separately
3	HGETALL user:1	Retrieve user info	{"name":"Alice","age":"30"}	User data fetched
4	HGETALL user:1:address	Retrieve address info	{"city":"NY","zip":"10001"}	Address data fetched
5	-	-	-	Execution ends after retrieval

💡 All commands executed; data stored and retrieved as separate hashes (referencing).

Variable Tracker

Key	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
user:1	none	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}	{"name":"Alice","age":"30"}
user:1:address	none	none	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}	{"city":"NY","zip":"10001"}

Key Moments - 2 Insights

Why do we store address in a separate key instead of inside user:1?

Storing address separately (referencing) allows updating address without changing user data. See execution_table rows 2 and 4 where address is stored and retrieved separately.

What happens if we embed address inside user:1?

Embedding means all data is in one key, so retrieval is faster but updating address requires rewriting the whole user record. This contrasts with referencing shown in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what data does the command at Step 3 retrieve?

A User's name and age

B User's address

C Both user info and address

D Nothing, it stores data

💡 Hint

Check the 'Data Stored/Retrieved' column at Step 3 in execution_table.

At which step is the address data stored separately?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Action' column in execution_table for storing address.

If we embed address inside user:1, how would variable_tracker change?

A user:1 would be empty

B user:1 would include address fields after Step 1

C user:1:address would still be separate

D user:1:address would contain user info

💡 Hint

Embedding means all data is stored in one key; see variable_tracker for keys and their data.

Concept Snapshot

Embedding vs Referencing in Redis:
- Embedding: store all related data in one key (hash).
- Referencing: store related data in separate keys, link by IDs.
- Embedding is faster for reads, less flexible for updates.
- Referencing allows independent updates, more flexible.
- Choose based on update frequency and data size.

Full Transcript

This visual execution shows how Redis stores related data using embedding or referencing. Embedding means putting all data in one key, making reads fast but updates harder. Referencing stores related data in separate keys, linked by IDs, allowing flexible updates. The example stores user info and address separately, showing commands and data changes step-by-step. Key moments clarify why separate keys help updates. The quiz tests understanding of data retrieval and storage steps.