mitkins

Options for persistent Pow session cache that are cost effective?

I’m currently looking at backend options for storing session cache data for Pow. I have a single server running on Gigalixir and I’m trying to keep it that way (for now) to keep costs low.

Looking through the Pow documentation, you can setup Mnesia - which is awesome. But in the case of a single node, it requires persistent disk storage for the cache to survive a pod/docker container replacement.

In the case of Gigalixir, file storage is ephemeral - so that means I have the following options:

Switch my deployment method to hot upgrades to prevent the container from being destroyed
Add a second node - then the cache can propagate itself as nodes go down and come back up
Implement the cache using Redis and find a 3rd party service

At this point, it looks like point 1) is the most cost effective solution.

Point 2) would take me out of the free tier and increase cost. Also, I’m not familiar with the mechanics of 1 node coming up and the next node going down. Is there enough time to copy the session cache - particularly if you only have 2 nodes? Does that mean I’d need 3 nodes at minimum?

I looked into point 3) with Google Memorystore - that introduces a cost of $35 per month. I’m not familiar with the cost of other services. A 3rd party solution may have other trade offs to consider - like network traffic costs (I’m currently in Google Cloud) and speed.

Is there anything else I should be thinking about?

22 comments

/phoenix #cache #gigalixir #pow

0 4006 22

2020-05-12 00:47:12 UTC

Most Liked

danschultzer

Pow Core Team

For anyone coming across this thread and looking for a Postgress store, I would recommend using this: GitHub - ZennerIoT/pow_postgres_store: A Pow store implementation that uses postgres as the backend · GitHub

Post #21

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #10

danschultzer

Pow Core Team

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.

Post #11