Denormalization for speed in Redis - Step-by-Step Execution

Concept Flow - Denormalization for speed

Start with normalized data

↓

Identify frequent joins/queries

↓

Duplicate related data into one record

↓

Store denormalized data in Redis

↓

Query single denormalized record

↓

Faster read, less joins

↓

Update duplicated data carefully

Denormalization copies related data into one place to speed up reads by avoiding joins, especially in Redis where data is stored as key-value pairs.

Execution Sample

Redis

HMSET user:1 id 1 name "Alice" age 30
HMSET order:101 id 101 user_id 1 total 50
// denormalized record
HMSET user_order:101 id 101 user_id 1 user_name "Alice" total 50
HGETALL user_order:101

Shows storing user and order separately, then a denormalized combined record for faster access.

Execution Table

Step	Action	Data Stored	Reason
1	Store user data	user:1 -> {id:1, name:"Alice", age:30}	Normalized user info
2	Store order data	order:101 -> {id:101, user_id:1, total:50}	Normalized order info
3	Create denormalized record	user_order:101 -> {id:101, user_id:1, user_name:"Alice", total:50}	Combine user and order for fast read
4	Query user_order:101	{id:101, user_id:1, user_name:"Alice", total:50}	Single read, no join needed
5	Update user name	Update user:1 and user_order:101	Must update duplicated data to keep consistency
6	Query user_order:101 again	{id:101, user_id:1, user_name:"Alice", total:50}	Fast read with updated data
7	End	-	Denormalization speeds up reads but requires careful updates

💡 Denormalization stops when data is combined for fast reads, but updates must keep duplicates consistent

Variable Tracker

Key	Initial	After Step 1	After Step 2	After Step 3	After Step 5	Final
user:1	none	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}	{id:1, name:"Alice", age:30}
order:101	none	none	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}	{id:101, user_id:1, total:50}
user_order:101	none	none	none	{id:101, user_id:1, user_name:"Alice", total:50}	{id:101, user_id:1, user_name:"Alice", total:50}	{id:101, user_id:1, user_name:"Alice", total:50}

Key Moments - 3 Insights

Why do we store the user name twice in both user:1 and user_order:101?

Because denormalization duplicates data to avoid joins during reads, so user_order:101 has user_name for faster access (see execution_table step 3).

What happens if we update user:1 but forget to update user_order:101?

The denormalized data becomes inconsistent, causing stale reads from user_order:101 (see execution_table step 5).

Why is querying user_order:101 faster than joining user:1 and order:101?

Because all needed data is in one record, so Redis fetches one key instead of multiple keys and combining them (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what data is stored in user_order:101?

A {id:101, user_id:1, total:50}

B {id:101, user_id:1, user_name:"Alice", total:50}

C {id:1, name:"Alice", age:30}

D None

💡 Hint

Check the 'Data Stored' column in execution_table row for step 3

At which step does the denormalized record get updated after a user name change?

A Step 5

B Step 3

C Step 2

D Step 6

💡 Hint

Look for the step mentioning update of duplicated data in execution_table

If we remove the denormalized record user_order:101, what happens to read speed?

A It becomes faster

B It stays the same

C It becomes slower due to multiple reads

D It causes errors

💡 Hint

Denormalization avoids multiple reads by combining data, see concept_flow and execution_table

Concept Snapshot

Denormalization stores duplicated related data together to speed up reads.
In Redis, this means combining user and order info into one key.
This avoids multiple lookups and joins.
Updates must keep duplicated data consistent.
Denormalization trades write complexity for read speed.

Full Transcript

Denormalization for speed means copying related data into one place to avoid multiple lookups. In Redis, we store user data and order data separately, then create a combined denormalized record with user and order info together. This lets us read all needed data with one key fetch, making reads faster. However, when user data changes, we must update the denormalized record too to keep data consistent. The execution steps show storing user and order, creating the denormalized record, reading it fast, updating duplicates, and reading again. This method improves read speed but requires careful updates.