Time-based event queues in Redis - Step-by-Step Execution

Concept Flow - Time-based event queues

Add event with timestamp

↓

Store event in sorted set

↓

Wait for current time

↓

Query events with score <= now

↓

Process events

↓

Remove processed events

↓

Repeat

Events are added with timestamps to a sorted set, then queried and processed when their time arrives.

Execution Sample

Redis

ZADD event_queue 1672531200 "event1"
ZADD event_queue 1672531300 "event2"
ZRANGEBYSCORE event_queue -inf 1672531250
ZREM event_queue "event1"

Add events with timestamps, get events due by a certain time, then remove processed events.

Execution Table

Step	Command	Action	Result	State of Sorted Set
1	ZADD event_queue 1672531200 "event1"	Add event1 with score 1672531200	1 (added)	[('event1', 1672531200)]
2	ZADD event_queue 1672531300 "event2"	Add event2 with score 1672531300	1 (added)	[('event1', 1672531200), ('event2', 1672531300)]
3	ZRANGEBYSCORE event_queue -inf 1672531250	Get events with score <= 1672531250	['event1']	[('event1', 1672531200), ('event2', 1672531300)]
4	ZREM event_queue "event1"	Remove event1 after processing	1 (removed)	[('event2', 1672531300)]
5	ZRANGEBYSCORE event_queue -inf 1672531250	Get events with score <= 1672531250 again	[]	[('event2', 1672531300)]
6	ZRANGEBYSCORE event_queue -inf 1672531350	Get events with score <= 1672531350	['event2']	[('event2', 1672531300)]
7	ZREM event_queue "event2"	Remove event2 after processing	1 (removed)	[]
8	ZRANGEBYSCORE event_queue -inf 1672531350	Get events with score <= 1672531350 after all removed	[]	[]

💡 No more events in the queue, all processed and removed.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 7	Final
event_queue	[]	[('event1', 1672531200)]	[('event1', 1672531200), ('event2', 1672531300)]	[('event2', 1672531300)]	[]	[]

Key Moments - 3 Insights

Why do we use a sorted set for the event queue?

Because sorted sets keep events ordered by timestamp (score), making it easy to query events due up to the current time (see execution_table rows 3 and 6).

What happens if we don't remove processed events?

They remain in the queue and will be returned again in future queries, causing duplicate processing (see execution_table row 5 shows event1 is gone after removal).

Why do we query with ZRANGEBYSCORE using -inf to current time?

To get all events with timestamps less than or equal to now, ensuring we process all due events (see execution_table rows 3 and 6).

Visual Quiz - 3 Questions

Look at the execution table, what is the state of the event_queue after step 2?

A [('event1', 1672531200), ('event2', 1672531300)]

B [('event2', 1672531300)]

C [('event1', 1672531200)]

D []

💡 Hint

Check the 'State of Sorted Set' column at step 2.

At which step does the event 'event1' get removed from the queue?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Look at the 'Command' and 'Action' columns to see when ZREM removes event1.

If we query ZRANGEBYSCORE with a timestamp less than 1672531200 at step 3, what would be the result?

A ['event1']

B []

C ['event2']

D ['event1', 'event2']

💡 Hint

Refer to step 3 where the query is up to 1672531250 and returns 'event1'; less than 1672531200 means no events.

Concept Snapshot

Time-based event queues in Redis use sorted sets.
Add events with ZADD using timestamps as scores.
Query due events with ZRANGEBYSCORE -inf to current time.
Process and remove events with ZREM.
This keeps events ordered and easy to manage by time.

Full Transcript

In Redis, time-based event queues are implemented using sorted sets. Each event is added with a timestamp as its score using ZADD. The queue stores events ordered by their timestamps. To process events due at the current time, we query the sorted set with ZRANGEBYSCORE from negative infinity up to the current timestamp. After processing, events are removed with ZREM to avoid reprocessing. This cycle repeats to handle events as their time arrives. The execution table shows adding two events, querying due events, processing, and removing them step-by-step. The variable tracker shows how the event queue changes after each operation. Key moments clarify why sorted sets are used, the importance of removing processed events, and how queries select due events. The visual quiz tests understanding of the queue state and commands at different steps.

Practice

1. What is the main purpose of using a Redis sorted set for a time-based event queue?

easy

A. To store events in a hash for quick lookup

B. To store events with timestamps as scores for ordered retrieval

C. To store only unique event names without timestamps

D. To store events without any order

Solution

1. Step 1: Understand Redis sorted sets

   Redis sorted sets store members with a score that determines their order.

2. Step 2: Apply to time-based event queues

   Using timestamps as scores allows events to be retrieved in chronological order.

3. Final Answer:

   To store events with timestamps as scores for ordered retrieval -> Option B

4. Quick Check:

   Sorted sets + timestamps = ordered event queue [OK]

Hint: Remember: sorted sets order by score (timestamp) [OK]

Common Mistakes:

• Thinking sorted sets don't keep order
• Confusing hashes with sorted sets
• Ignoring the timestamp as score

2. Which Redis command correctly adds an event with a timestamp score to a sorted set named events?

easy

A. SADD events 1625097600 "event1"

B. HSET events 1625097600 "event1"

C. ZADD events 1625097600 "event1"

D. LPUSH events 1625097600 "event1"

Solution

1. Step 1: Identify the command for sorted sets

   ZADD adds members with scores to sorted sets; others are for different data types.

2. Step 2: Check syntax correctness

   ZADD events 1625097600 "event1" adds "event1" with score 1625097600 to sorted set events.

3. Final Answer:

   ZADD events 1625097600 "event1" -> Option C

4. Quick Check:

   ZADD = add to sorted set [OK]

Hint: Use ZADD for sorted sets, not SADD or HSET [OK]

Common Mistakes:

• Using SADD which is for sets without scores
• Using HSET which is for hashes
• Using LPUSH which is for lists

3. Given the sorted set events with members and scores:
{"event1": 1000, "event2": 1500, "event3": 2000}
What will the command ZREVRANGEBYSCORE events 1500 -inf return?

medium

A. ["event1"]

B. ["event3", "event2", "event1"]

C. ["event1", "event2"]

D. ["event2", "event1"]

Solution

1. Step 1: Understand ZREVRANGEBYSCORE command

   This command returns members with scores between max and min in descending order.

2. Step 2: Apply to given scores

   Scores ≤ 1500 are event1 (1000) and event2 (1500). Descending order: event2, event1.

3. Final Answer:

   ["event2", "event1"] -> Option D

4. Quick Check:

   Descending scores ≤ 1500 = event2, event1 [OK]

Hint: ZREVRANGEBYSCORE returns descending order by score [OK]

Common Mistakes:

• Confusing ascending with descending order
• Including events with scores above max
• Misreading score boundaries

4. You run this Redis command to fetch due events:
ZREVRANGEBYSCORE events 1625097600 -inf
But you notice the same events are returned repeatedly. What is the likely mistake?

medium

A. Not removing processed events from the sorted set

B. Using ZREVRANGEBYSCORE instead of ZRANGEBYSCORE

C. Using the wrong key name for the sorted set

D. Using a timestamp that is too high

Solution

1. Step 1: Understand event queue behavior

   After processing events, they must be removed to avoid duplicates.

2. Step 2: Identify cause of repeated events

   If events are not removed, the same events appear on every fetch.

3. Final Answer:

   Not removing processed events from the sorted set -> Option A

4. Quick Check:

   Remove events after processing to avoid repeats [OK]

Hint: Always delete processed events from sorted set [OK]

Common Mistakes:

• Thinking order command causes repeats
• Ignoring event removal step
• Assuming wrong key name causes repeats

5. You want to implement a Redis time-based event queue that fetches all events due up to now and removes them atomically to avoid duplicates. Which sequence of commands is best?

hard

A. Use ZRANGEBYSCORE to get events ≤ now, then ZREM to remove them

B. Use ZREVRANGEBYSCORE to get events ≥ now, then ZREM to remove them

C. Use ZRANGEBYSCORE with a future timestamp, then LPUSH to add events

D. Use SPOP to pop events from a set

Solution

1. Step 1: Fetch due events with ZRANGEBYSCORE

   ZRANGEBYSCORE with max = current timestamp fetches all events due up to now.

2. Step 2: Remove fetched events with ZREM

   Removing them prevents duplicates; doing both steps atomically avoids race conditions.

3. Final Answer:

   Use ZRANGEBYSCORE to get events ≤ now, then ZREM to remove them -> Option A

4. Quick Check:

   Fetch ≤ now + remove = atomic event processing [OK]

Hint: Fetch with ZRANGEBYSCORE ≤ now, then remove with ZREM [OK]

Common Mistakes:

• Using ZREVRANGEBYSCORE with wrong score range
• Using sets or lists instead of sorted sets
• Not removing events after fetching