Buttondown no longer runs Redis
Buttondown no longer runs Redis!
I added it years ago for the same reason almost every Django app has Redis: that's just what you do. Workers wanted a queue, the queue wanted a broker, the broker was Redis. The cache wanted a backend, the backend was Redis. Sessions wanted a store, the store was Redis. And then it festers from there. Though "festers" is unkind: I have no qualms with Redis as a technology, I just have qualms with twice as many datastores as I ought to have.
I wrote earlier this year about pulling django-rq and the worker queue off of Redis. What was left after that was mostly small: rate-limit counters, a few short-TTL caches, an idempotency-key fast-path, and session storage. Not enough to really cause any issues, but we're working on our Heroku migration Stay tuned for more., and big infrastructural changes are made slightly easier by one fewer dependency, even if it's a fairly static one.
When I actually measured the replacements against production Postgres, they came in well under the Redis round-trip they were replacing, which has to cross AWS regions to reach our RedisCloud instance. The "fast in-memory store" was, in this configuration, slower than the database itself. (Thanks, PlanetScale!)
The few caches that didn't have a good home in Postgres became per-process in-memory dicts. We deploy enough times a day that a process-local cache lives long enough to do its job and gets cleared often enough that staleness isn't meaningfully real.
When I wrote yesterday about maintenance costs, this is exactly the kind of thing I had in mind. It is both wild and accurate to say that the Buttondown stack, as of right this second, is dramatically simpler — let alone more stable — than it was two years ago.