[mattgreenrocks]

> I can't help but think passing ids and finding the object again on the other side is bad design.

It is good design. Why? Because you don't want to pass mutable state (read: your user model) across thread/process boundaries if you can help it. What if the mailer modifies it? What if the caller modifies it while the mailer is working with it? It may no longer be valid. Rather than trying to reason about all possible states it could be in, it's easier just to make the job bootstrap itself with all the data it needs.

Confining instances to threads is far more sane than using mutexes and locks or relying on your runtime's GIL to watch out for you.

[nirvdrum]

Since you're unlikely to be sharing memory with your background processor, what you'd really be doing is marshaling the object on enqueue and unmarshaling on decode. In that case, you're no more susceptible to further modifications to the data than you would be with a DB lookup.

There of course may be other issues with marshaling. E.g., marshaling of procs is particularly tricky. But I've been marshaling with sidekiq for the past couple months and really haven't run into any problems. And it cleaned up the code a fair bit because I basically treat it as an RPC without any of the ceremonious DB lookups at the start of every async method.