Make database persistent

[lazerwalker]

It would be great for many reasons if our data stayed constant from year to year.

A few potential ways to handle this:

• Pay Azure enough money for a Redis instance with built-in data persistence. This seems prohibitive: it jumps from $40/mo to $400/mo.
• Manually write scripts that back-up redis to disk and restore from disk. Feels janky, but easy. Needs to be a script that's secure and with easy instructions but not gated behind in-app admin access, since losing DB data means losing admin access
• Write a complex persistence layer that double-writes to both cache and DB, and tries the cache before hitting DB. This is the most robust option, but also the most complex.

My gut instinct is the middle option is the right complexity sweet spot: at the end of each year, we save the state of the social space, and next year we restore it. Ideally restoring is easy enough that it's not a problem to do mid-year as we resume dev. Also has the benefit of letting us wipe all dev work before the event itself. But open to suggestions.

[lazerwalker]

Manually writing scripts is more work than I want. The built-in redis dump command requires disk access (which we don't have), so we'd basically be looking at manually creating an allow-list of all keys we should serialize to disk. I think that's still less work than a persistence layer consisting of both a db and redis.

Next steps for me: investigate how disparate our use of keys are. I know 100% of our key use is limited to our one redis file, but the fact that we use runtime-generated keys (i.e. based on user IDs and room names) might complicate things.

[lazerwalker]

That does not require being clever. Redis has a KEYS * command that dumps all key names. There's no nifty function to get all values, but for an infrequently-run dump script it's reasonable to iterate through that list of keys and perform a bunch of GETs.

[lazerwalker]

We're using KEYS to power the dynamic room editor. Which is just to confirm that's possible.