Options for persistent Pow session cache that are cost effective?

What kind of information are you trying to persist?

An alternative is to use the DB for cache store. The cache stores are built around key-value store with TTL so it’s not really the right tool for the job, but it’s worth looking into if your first option doesn’t work well enough.

The Redis store cache backend guide is short enough to give you a good idea how the cache should work: Redis cache store backend — Pow v1.0.39

I would probably set it up as a GenServer similar to the ETS cache: pow/lib/pow/store/backend/ets_cache.ex at v1.0.13 · pow-auth/pow · GitHub

Just remember to handle TTL so expired entries are cleared out. In the ETS and Mnesia cache stores invalidator callbacks are used, and if you want to do this you have to make sure that the invalidators are initiated again on restart (same as how the Mnesia cache handles it).

However, it’ll likely be easier if you just deal with it by using the relational structure in SQL, and add the namespace, key, value and expiration as individual columns. Maybe user id should be a column too. Then you can periodically flush the table for expired entries instead.

Hello!

It’s a user/session store. I haven’t looked into the data that Pow’s managing, but I’m assuming it stores the fields of the user table plus some meta data.

Is the point to avoid querying the database? Are you running into concrete performance issues or is caching this data speculative?

Oh no, performance isn’t a concern yet (I have 1 regular user!). The main issue I’m facing right now is that I don’t want users kicked off the website just because I push an update. Since Pow utilises a session cache, I’m just trying to find the best way to persist the cache (without incurring cost).

@danschultzer, awesome information (as usual). I might have a stab at implementing a db cache and see how it goes. In the interim, I’ll push out hot upgrades

It’s a nice advantage, but it’s mostly about ephemeral storage. Often the DB isn’t the right place for that.

Yeah, it usually consists of a randomly generated key and a map with user struct and some metadata. PowPersistentSession and PowResetPassword also uses the backend store.

Ephemeral storage of what? If it’s ephemeral, why does it need to be also persisted between reboots?

Because a session or reset token may have been created just before deploy/reboot.

If it’s an actual cache then it doesn’t really matter, the canonical state is either the database or the user token (if doing something like JWT) and then the cache can be rebuilt as requests come in. If the “cache” is actually the canonical store then that’s an issue, and neither redis nor mnesia nor hot loading are particularly durable solutions. If the cache is the canonical store, it is not ephemeral.

I get what you’re saying, the credentials store or reset token store is the source of truth and can’t be ephemeral. Behind the store layers (like credentials store that contains sessions), I use a cache layer that handles short lived key-value items. Both layers can be replaced with whatever you need.

I have found it most practical to treat what is stored in the cache largely as ephemeral data, that can be flushed without any major downside. E.g. a session shouldn’t exist after the user leaves the site. By default ETS is used for this layer, but since that’s inconvenient in a production environment, Mnesia or Redis is recommended so the tokens can survive between restarts.

This data shouldn’t be backed up, the data persisted to the disk is temporary, and if a node connects to a cluster, any local cache data it may have in memory (or on disk) has to be overridden by the cache in the cluster. It isn’t meant to be durable. The user struct with the credentials used for authentication, is the only thing that has to be persisted.

There may be a better term for it, but I hope this clarifies what the data is in the cache backend in Pow.