Deployment

Faktory is designed to run as a single, widely available service on your network, much like postgresql or mysql.

Standalone

Faktory runs as a single process on a machine, exposing port 7419 (workers) and port 7420 (HTTP). When Faktory boots up, it starts Redis as a child process and uses Redis for local data storage. This child Redis is not available on the network for security reasons. Redis will persist all data to the -d directory, which defaults to /var/lib/faktory/db when running in production mode (-e production).

|- faktory (port 7419, 7420)
   |
   |- redis (found at /var/lib/faktory/db/redis.sock)
      |
      |- data in /var/lib/faktory/db/faktory.rdb

In my experience this design is really reliable, especially if the app is also running on the same machine. They say "don't put all your eggs in one basket" but I've found for computing services, having lots of baskets just leads to more frequent failures and much more complex DevOps. Keep it simple.

Remote

If you don't wish to manage Redis at all and want something that will provide replication out of the box, Faktory Enterprise can use the remote Redis feature in order to use a SaaS like Elasticache. Two instances of Faktory cannot share the same Redis database and Redis Cluster is not supported. If you need to fail over to a replica, you restart Faktory with the updated REDIS_URL.

High Availability

Faktory does not provide a more complex high availability clustered mode of operation. It relies on Redis' well-tested replication for data persistence and failover. In my experience, high availability, clustered modes of operation are often buggy with little-tested edge cases and far more expensive to run and maintain. Faktory's ethos prefers simplicity to provide better availability and low cost of operation. At some point, adding more complexity to a distributed system will only lead to fewer nines, not more.