That's a great question. I chose Redis for 2 reasons:
* Simple to use
* Compatibility with other systems like Sidekiq/Resque. Out of the box it will understand their clients.
My experience with Mnesia is close to none but I know it's not trivial to deal with split brain scenarios for example. It's also complicated to connect multiple nodes for my use case (using docker) and also to deal with moving instances inside a cluster. I would need to care about the locality of the data.
One can use any Redis service (AWS Elasticache, Redis Labs) and not care about maintaining a database. The Verk user just needs to have a working Redis database.
I'm pretty sure that having the database in the same space as the job processing system would speed up things. I would love to see a project that tried this approach. Probably not using JSON but simply Erlang terms.
Honest question, what is redis then? I've used it for all sorts of reasons, it seams like a swiss army knife, caching, queing, pub/sub, persistence, non-persistence all-in-one utensil. You can do a lot with it, and if it's already in the stack, it's a lot easier for others to reason with.
* Simple to use
* Compatibility with other systems like Sidekiq/Resque. Out of the box it will understand their clients.
My experience with Mnesia is close to none but I know it's not trivial to deal with split brain scenarios for example. It's also complicated to connect multiple nodes for my use case (using docker) and also to deal with moving instances inside a cluster. I would need to care about the locality of the data.
One can use any Redis service (AWS Elasticache, Redis Labs) and not care about maintaining a database. The Verk user just needs to have a working Redis database.
I'm pretty sure that having the database in the same space as the job processing system would speed up things. I would love to see a project that tried this approach. Probably not using JSON but simply Erlang terms.