[rschmukler]

The choice of Mongo vs Redis was intentional. Without configuration Redis doesn't guarantee persistence as well as Mongo. Since Redis is often used for non-critical data such as sessions I didn't want to enforce sacrificing performance of sessions for persistence.

[babby]

Looking at these scheduling modules, I wonder to myself why saving a .json file wouldn't be more simple. Filesystem cache, available to all workers on the system and no dependencies required.

I mean, if you're worried about cluster workers file reading being slower than a db connection, the json store could be write-only most of the time and only read on app startup while schedules are synced over cluster messaging.

[rschmukler]

In my mind there are a few reasons, but indeed it could definitely be implemented with a flat file. Sometimes you aren't guaranteed write-access to a file on the system, especially if you're using a PAAS like Heroku. That also complicates things if you want to build something to view/edit the data in an isolated instance. These are just the reasons that come to the top of my head, but in reality you're right, this could be finessed to be done with just a flat file.

[babby]

Good points. Perhaps structuring it in a way to allow for a flat file or redis/nosql/sql might push a particular schedule module into greater favor, at least for those of us who want our apps to consist of minimal different db methods.