<story><title>Faktory, a new background job system</title><url>http://www.mikeperham.com/2017/10/24/introducing-faktory/</url></story><parent_chain></parent_chain><comment><author>jitl</author><text>It seems nuts to me to introduce a stateful queue system like this where the persistence story is “data’s out there on a single node in some kind of disk format, hope it doesn’t go missing!”&lt;p&gt;I guess this style significantly reduces setup friction, but it’s almost an irresponsible design in a universe where the average cloud provider is telling you, “your compute instances may vanish at any time.” If this used Kafka, Redis, MySQL, or another well-known stand-alone  data store, I know my data is replicated, and I can recover my enqueued jobs if Somethimg Bad happens.&lt;p&gt;I like the nice UI and the simple API, but there’s no way this will replace Resque or any Kafka-based-job-whatever at my place of work.</text></comment>
<story><title>Faktory, a new background job system</title><url>http://www.mikeperham.com/2017/10/24/introducing-faktory/</url></story><parent_chain></parent_chain><comment><author>manigandham</author><text>You can just use Redis, Kafka, or better yet use Google&amp;#x27;s Cloud Pub&amp;#x2F;Sub or Azure Service Bus for an extremely cheap and highly-reliable system that already has all of these features included.&lt;p&gt;What exactly is the use-case for an entirely new and separate system that looks like it&amp;#x27;s single-node only?</text></comment>