Yes, that’s precisely why doing events / reactions versus background jobs is better approach IMHO. You don’t schedule a job, you send out an event somewhere. That somewhere is a queue. Then some things can pick up that event and act upon it. The major advantage of thinking this way is that you are detaching the event from implementation. If you save to database module name / function / arguments to be executed, you are also prone to the code changes - i.e. suddenly the module is not available after deploy, or it’s taking now 3 not parameters and your background queue is going to get messed up.

If you are writing your Rails app properly, i.e. there is not much logic in the models themselves, and you have stuff extracted to services, you can quite easily connect from Ecto to the same database Rails uses. It’ll understand it well, and can manipulate the same data Rails does. You obviously might need to re-implement some of the logic in Elixir but generally that’s what I would also do in Rails - background job services would be implementing own logic wherever possible to keep it isolated.

In case anyone is still coming to this thread (based on views it appears so). Another good option for running persistent background jobs in Elixir is https://github.com/sorentwo/oban/ (this is the job library that I like to use).

If you’re wondering if you can do this purely in Elixir, you can. However, you are going to need to roll your sleeves up and get dirty learning OTP. Personally, I think implementing a job queue/event dispatcher is a great way to learn Elixir/OTP. The use case hits on most of the OTP sweet spots and requires you to dig a little.

You’ll need to put some effort in up front to understand how advanced you want your queue to be. Specifically, how durable should your jobs be and should they be distributed? If your server crashes or restarts is it OK to lose all your jobs? Do you need/want multiple servers handling jobs? If you need durability and distribution then you’re probably better off reaching for something like Exq or Honeydew. If not then Task’s might be a good starting point.

I/my team have done pretty much this twice, two different approaches. In first project we used RabbitMQ queues for background jobs. This was a design decision from start, so we could have workers processing those written in whatever we wanted. This is a good approach if you are already using RabbitMQ.

If you are not, but you are using Resque or Sidekiq, there might be easier path by using https://github.com/akira/exq - I only have limited experience with that library myself, but from what I have been told it works as advertised.

Reading back to your original question, are you running into specific problems with your Rails job implementations? You say you think you could do some things more efficiently in Elixir, but are there any actual problems on the Rails side? Is there a goal you’re trying to accomplish that moving your jobs to Elixir would help with (i.e. infrastructure costs)? Might be a premature optimization if you don’t see or aren’t expecting any issues.