Why streams handle event logs in Redis - Visual Breakdown

Concept Flow - Why streams handle event logs

Event Occurs

↓

Create Event Entry

↓

Append Entry to Stream

↓

Stream Stores Ordered Events

↓

Consumers Read Events in Order

↓

Process or Archive Events

Events happen and are recorded as entries appended to a stream. The stream keeps events in order so consumers can read and process them sequentially.

Execution Sample

Redis

XADD mystream * event_type login user_id 123
XADD mystream * event_type logout user_id 123
XRANGE mystream - +

Add two event entries to a Redis stream and then read all events in order.

Execution Table

Step	Command	Action	Stream State	Output
1	XADD mystream * event_type login user_id 123	Add login event	[{id: 1680000000000-0, event_type: login, user_id: 123}]	1680000000000-0
2	XADD mystream * event_type logout user_id 123	Add logout event	[{id: 1680000000000-0, ...}, {id: 1680000000001-0, event_type: logout, user_id: 123}]	1680000000001-0
3	XRANGE mystream - +	Read all events	[{id: 1680000000000-0, ...}, {id: 1680000000001-0, ...}]	[{id: 1680000000000-0, event_type: login, user_id: 123}, {id: 1680000000001-0, event_type: logout, user_id: 123}]
4	End	No more commands	[{id: 1680000000000-0, ...}, {id: 1680000000001-0, ...}]	Execution complete

💡 All events added and read; stream maintains order and stores event logs.

Variable Tracker

Variable	Start	After 1	After 2	Final
mystream	empty	[{1680000000000-0: login event}]	[{1680000000000-0: login event}, {1680000000001-0: logout event}]	[{1680000000000-0: login event}, {1680000000001-0: logout event}]

Key Moments - 2 Insights

Why does the stream keep events in order?

Because each event is appended with a unique increasing ID (timestamp-based), the stream stores events sequentially as shown in execution_table rows 1 and 2.

How do consumers know which events to read next?

Consumers read events by their IDs in order, as shown in execution_table row 3 where XRANGE reads all events from oldest to newest.

Visual Quiz - 3 Questions

Look at the execution_table, what is the stream state after the first XADD command?

A One event with event_type login

B Two events: login and logout

C Empty stream

D Stream deleted

💡 Hint

Check execution_table row 1 under Stream State

At which step does the stream contain two events?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at execution_table rows 1 and 2 Stream State column

If a new event is added after step 2, how would the stream state change?

A It would remain the same

B It would remove the first event

C It would have three ordered events

D It would overwrite the last event

💡 Hint

Streams append events, so new events add to the end as shown in variable_tracker

Concept Snapshot

Redis streams store event logs by appending entries with unique IDs.
Each event is kept in order for reliable processing.
Consumers read events sequentially using XRANGE or XREAD.
Streams are ideal for event logging and messaging.
They keep data immutable and ordered for audit and replay.

Full Transcript

Redis streams handle event logs by appending each event as a new entry with a unique timestamp-based ID. This keeps events in the order they occurred. When an event happens, it is added to the stream using the XADD command. Consumers can then read these events in order using commands like XRANGE. This ordered, append-only structure makes streams perfect for logging events reliably and processing them sequentially. The execution trace shows adding two events and reading them back, demonstrating how streams maintain order and store event data.

Practice

1. Why are Redis streams well-suited for handling event logs?

easy

A. Because they only store one event at a time

B. Because they delete old events automatically

C. Because they store events in order with unique IDs

D. Because they require complex setup to use

Solution

1. Step 1: Understand Redis streams storage

   Redis streams store events sequentially with unique IDs, preserving order.

2. Step 2: Match this to event log needs

   Event logs need ordered, unique entries to track actions accurately.

3. Final Answer:

   Because they store events in order with unique IDs -> Option C

4. Quick Check:

   Streams = Ordered unique events [OK]

Hint: Streams keep events ordered with unique IDs [OK]

Common Mistakes:

• Thinking streams delete old events automatically
• Believing streams store only one event
• Assuming streams need complex setup

2. Which Redis command is used to add a new event to a stream?

easy

A. XREAD

B. XADD

C. XRANGE

D. XDEL

Solution

1. Step 1: Identify command to add events

   XADD is the Redis command designed to add new entries to a stream.

2. Step 2: Differentiate from other commands

   XREAD reads events, XRANGE queries a range, XDEL deletes entries.

3. Final Answer:

   XADD -> Option B

4. Quick Check:

   XADD = Add event [OK]

Hint: XADD adds events to streams [OK]

Common Mistakes:

• Confusing XADD with XREAD or XRANGE
• Thinking XDEL adds events
• Using XRANGE to add events

3. Given the Redis stream commands below, what will XRANGE mystream - + return?

XADD mystream * event "login" user "alice"
XADD mystream * event "logout" user "bob"

medium

A. All events in 'mystream' from the oldest to newest

B. Only the first event added to 'mystream'

C. An error because XRANGE needs a count parameter

D. No events because the stream is empty

Solution

1. Step 1: Understand XRANGE command

   XRANGE with '-' and '+' returns all entries from oldest to newest in the stream.

2. Step 2: Check stream content after XADD commands

   Two events were added: a login by alice and a logout by bob.

3. Final Answer:

   All events in 'mystream' from the oldest to newest -> Option A

4. Quick Check:

   XRANGE - + = all events [OK]

Hint: XRANGE - + returns all stream events [OK]

Common Mistakes:

• Thinking XRANGE returns only one event
• Believing XRANGE requires a count parameter
• Assuming stream is empty after XADD

4. You run the command XADD mystream * event but get an error. What is the likely cause?

medium

A. XRANGE command is required before XADD

B. Using * instead of a specific ID

C. Stream 'mystream' does not exist

D. Missing field-value pairs after the event name

Solution

1. Step 1: Check XADD syntax requirements

   XADD requires field-value pairs after the ID; 'event' lacks a value.

2. Step 2: Validate other options

   Using '*' is correct for auto ID, streams can be created automatically, and XRANGE is unrelated.

3. Final Answer:

   Missing field-value pairs after the event name -> Option D

4. Quick Check:

   XADD needs field-value pairs [OK]

Hint: XADD needs pairs: field and value [OK]

Common Mistakes:

• Thinking * is invalid for ID
• Assuming stream must exist before XADD
• Believing XRANGE must run first

5. You want to track user actions in a Redis stream but only keep the last 100 events to save memory. Which command option helps achieve this?

hard

A. XADD mystream MAXLEN ~ 100 * event "login" user "alice"

B. XADD mystream * event "login" user "alice" COUNT 100

C. XADD mystream * event "login" user "alice" MAXLEN 100

D. XADD mystream * event "login" user "alice" LIMIT 100

Solution

1. Step 1: Understand MAXLEN option in XADD

   MAXLEN limits stream length; '~' makes it approximate for better performance.

2. Step 2: Identify correct syntax for trimming

   XADD mystream MAXLEN ~ 100 * event "login" user "alice" uses 'MAXLEN ~ 100' which trims stream to about 100 entries efficiently.

3. Final Answer:

   XADD mystream MAXLEN ~ 100 * event "login" user "alice" -> Option A

4. Quick Check:

   MAXLEN ~ 100 trims stream length [OK]

Hint: Use MAXLEN ~ 100 to trim stream length efficiently [OK]

Common Mistakes:

• Using MAXLEN without ~ causes slower trimming
• Using COUNT or LIMIT which are invalid here
• Not trimming stream and causing memory issues