Queues (and other stateful information) should be managed in a DB/kv store, not in memory

[mikeage]

Currently, the queues and other information about state is kept in RAM, but this means that a restart of the service loses all of the information. It also means it can't be scaled behind an LB (probably not relevant for a single user), and to be honest, I'm not quite sure how this can work in a lambda, where there's no persistence.

Ideally, I would think that something like redis would be a better place to store persistent data.

[fergyfresh]

In order for the Queues to work in Lambda we will need to not have them in memory. I really only use Play some music intent.

[fergyfresh]

But yeah. the LB thing isn't something we should design around because this hack shouldn't be distributed to the scale that would require a LB tbh.

[mikeage]

Fair enough, and AWS ELBs, ALBs, and NLBs are not cheap, at least compared to a lightly used lambda or EC2. But even without the LB issue, lambdas don't keep their memory for too long...

[fergyfresh]

They keep it for long enough to run through the 25 songs in the i'm feeling lucky playlist, or atleast that's been my experience thus far. XD