6 ms·
> We wanted to communicate this as early as possible Two months is a bit short for a database change, don't you think?
by julianbuse 4y ago
> We wanted to communicate this as early as possible
Two months is a bit short for a database change, don't you think?
- calgoo 4y agoEspecially in summer! I can imagine that there are quite a few people who will have to change their vacation plans.
- heretogetout 4y agoMoving to a new instance of ought to be trivial -- send writes to both for a while, once the latest ttl is hit move reads. This does assume you're doing something same like setting short ttls (no more than a day, maybe a week).
- yashap 4y agoRedis isn’t used exclusively as a cache. It’s used a lot as a job queue, as an event bus, for session storage, etc. Some even use it as a core source of truth database, though this is rarely a good idea IMO.
- heretogetout 4y agoI think each of those is nearly as easy to update, except the source of truth. Probably shouldn't ever go on vacation if redis is your source of truth!
- yashap 4y agoYeah, agreed, though if you’re using Redis as central pub/sub infra in an environment with tonnes of different services who produce and consume events, a migration can get tedious. Certainly not as bad as traditional DB migrations, but doing it under a short timespan could still be a pain.
- RulerOf 4y agoThe first thing that comes to my mind when I see a Redis instance is "how do I flush it?"
- zeckalpha 4y agoRedis is not a database. Please, do not use it for persistence. I have been bitten too many times by services that tried.
- avinassh 4y agoI am curious, what all kinds of issues you ran into?
- deleted 4y ago[deleted]
- zeckalpha 4y agoData loss, particularly under high write volume. Partitioning can help. There are a few ways to enable persistence, but you should still treat it like a cache, like you would Memcache or Elasticsearch.