@Damian_Danev the delay is really depends on the amount of such expire keys you will have. Redis has 2 expire Technics, one is on access and the other called active expire and happened in the background on Redis cron job. So if you have a lot of such expire keys that you do not touch, the active expire might decide that it runs to long and it should stop and continue on the next cron job cycle. Good news is that you can configure the amount of efforts to put on the active expire phase:
Redis reclaims expired keys in two ways: upon access when those keys are
found to be expired, and also in background, in what is called the
“active expire key”. The key space is slowly and interactively scanned
looking for expired keys to reclaim, so that it is possible to free memory
of keys that are expired and will never be accessed again in a short time.
The default effort of the expire cycle will try to avoid having more than
ten percent of expired keys still in memory, and will try to avoid consuming
more than 25% of total memory and to add latency to the system. However
it is possible to increase the expire “effort” that is normally set to
“1”, to a greater value, up to the value “10”. At its maximum value the
system will use more CPU, longer cycles (and technically may introduce
more latency), and will tollerate less already expired keys still present
in the system. It’s a tradeoff betweeen memory, CPU and latecy.
active-expire-effort 1
You said that the events are ordered by the timestamp so most of the time the next timestamp would be the trigger to continue processing. So IIUC there will be a respectively small amount of times where you reply on this expire event, only when data stop arriving there might be a key per stock where you need to reply on its expiration (is that correct?). How many stocks are we talking about?