Time-based event queues in Redis - Time & Space Complexity
When using Redis for time-based event queues, it is important to understand how the time to process events grows as more events are added.
We want to know how the number of operations changes when the queue gets bigger.
Analyze the time complexity of the following Redis commands used to manage a time-based event queue.
ZADD event_queue 1650000000 "event1"
ZADD event_queue 1650000050 "event2"
ZADD event_queue 1650000100 "event3"
ZRANGEBYSCORE event_queue -inf 1650000050
ZREM event_queue "event1"
This code adds events with timestamps to a sorted set, retrieves events up to a certain time, and removes processed events.
Look at what repeats when managing the queue.
- Primary operation: Retrieving events with
ZRANGEBYSCOREwhich scans events by score (time). - How many times: This happens every time we want to process events up to a certain time.
As the number of events (n) grows, the time to add an event stays quite stable, but retrieving events depends on how many events match the time range.
| Input Size (n) | Approx. Operations for ZRANGEBYSCORE |
|---|---|
| 10 | About 10 or fewer operations |
| 100 | About 100 or fewer operations |
| 1000 | About 1000 or fewer operations |
Pattern observation: The retrieval cost grows roughly in proportion to the number of events returned.
Time Complexity: O(log n + m)
This means it takes a small time to find where to start, plus time proportional to the number of events returned.
[X] Wrong: "Retrieving events from the queue always takes the same time no matter how many events there are."
[OK] Correct: The time depends on how many events match the time range, so more events means more work.
Understanding how Redis handles time-based event queues helps you explain efficient event processing in real systems.
"What if we changed from ZRANGEBYSCORE to using a Redis stream for events? How would the time complexity change?"