Question

I’m starting a green field project. In it, we would like to have a QUEUE that has expiries. So I add an key and that item expires in .. say .. 20 mins.

The queue is expected to be pretty large. 10’s of thousands of keys with different expiry times.

Straight away I thought of maybe using ServiceStack.Redis and of course, Redis 🙂

So far, this is hopefully going to be hosted on AppHarbor + RavenDb + RedisToGo. Redis Key will be the RavenDb Id’s. (strings – eg. users/1 or whatever)

Questions

1. Can I leverage SS.Redis to add items to a redis queue with an expiry? (I’m assuming, yes. for eg. typedClient.ExpiresAt(..))
2. Can I leverage RedisToGo as the cloud hosted redis provider and use SS.Redis as the client? (again, assuming yes and yes)
3. When an item expires, can i get it to do a REST GET or POST to some URL? – so i can ‘handle’ an expiry? (No idea).

Answer 1

1. In redis, it is the key that has the expiry, not individual items in a list/set/hash/etc. If you have a single queue (I assume that is a list in redis terminology, pushing/popping at different ends), then your expiry applies to all items in that same queue. There isn’t really a good metaphor for a list (etc) that would allow per-item expiry. Frankly, the easiest thing is probably to include the logical expiry in the payload, and just discard items as you pop them if they are overdue

2. As the client has access to the server over the selected port, you should be ok – regardless of the particular client and server/provider; but it would presumably be trivial to verify this if you have those services.

3. Redis at the current time doesn’t include any expiry trigger functionality, but this has been proposed and (seemingly) accepted for the 2.8 release (see discussion here); redis won’t itself do any posts to urls, but hypothetically you could just listen on the event channel and do that in your code

But again, it comes back to the issue of expiry on keys vs items.