Why we beamed our background jobs off Redis

Every Ruby team eventually needs work to happen later: send the email, resize the image, sync the account. And almost every Ruby team reaches for the same answer — put a queue in Redis, or poll a table in Postgres.

Both work. Both are also tools that were never designed to be message brokers. We kept running into the edges: memory that has to fit the whole backlog, scaling that only goes up, and a quiet fear that a restart at the wrong moment drops something on the floor.

Messaging first, storage second

NATS flips the priorities. It is a ~20 MB binary that idles at around 10 MB of RAM, persists streams to disk, and clusters horizontally out of the box. Lose a node and the others take over — no message loss, no sentinel dance.

One gem, two primitives

Most job libraries stop at jobs. If you also need to consume a continuous event feed, that's a second system, a second config and a second fleet of workers. Cosmonats ships both as first-class citizens, sharing one server, one config and one CLI.

class ReportJob
  include Cosmo::Job
  options stream: :critical, retry: 5, dead: true

  def perform(report_id)
    Report.find(report_id).generate!
  end
end

ReportJob.perform_in(30.minutes, 42)

Time travel is a feature

Because messages live on disk, any consumer can rewind — to the beginning of time, to a timestamp, or only to new messages. Pipeline down for three hours? Replay from the crash. New service needs history? Start it from the first message. Weird production bug? Replay the exact sequence that caused it.

The UFO never drops the cow

That's the bitsbeam idea in one picture: the cow goes up whole, or it doesn't go at all. Cosmonats is our first craft built on that promise — tens of millions of jobs processed in production, and counting. More transmissions soon.