Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One example that jumps to mind was that I was able to rip out several hundred lines of fiddley retry and backoff code and replace it with fine-grain-timed repeating events.

One advantage to doing this in Redis was that our events aren't just "run a program" (though we can do that); we can also push onto a queue that consumers BLPOP from, or send a pubsub message to a bunch of consumers, or increment counters.

later

Makes you think, it's nice that Redis is minimal, but a core feature that might work really nicely with Redis is timer support.



You will get said timer support in Redis 2.8 with the ability to subscribe to keyspace events, which includes keys expiring (with millisecond resolution). https://github.com/antirez/redis/issues/594

  psubscribe __keyevent@0__:expired cron_*

  psetex cron_run-me-in-1s 1000 0


It's not clear to me from the writeup if you'll get notification when the key actually expires, or when the key is expired because someone tried to access it.

Currently keys don't actually really expire from the datastore until someone tries to access it after its TTL runs out. Changing redis so it will actually actively expire keys at the precise time the TTL runs down sounds expensive... but I would love that feature nonetheless.


Redis's expirey strategy has changed as of Redis 2.6, which does have Redis actively expiring keys.


Ah! I did not know this! This may make a few things simpler for me...


Awesome! I've been waiting for this for a while.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: