Так сложилось, что мы пользуемся для всяких асинхронных задач DelayedJob. Удобно, что этот тот же постгрес, из коробки комфортный API, разумные дефалтовые настройки (например интервалы сколько раз запускать упавшую задачу).

Однако если задуматься, то DJ - эта та еще штука и при эксплуатации нужно знать его особенности. Когда вы делаете User.find(1).delay.send_hello, то в базу сериализуется объект типа User и факт, что к нему нужно применить метод :send_hello. Одноко, чтобы это работало как магия, при восстановлении AR-объекта, на самом деле он берется прямо из базы psych_ext.rb#L30-L65.

В большинстве случаев это просто работает, но могут быть необычные сайд эффекты. Если метод применяется к объекту, который успели уже удалить, то будет ошибка 500. Или предположим, что пользователь два раза быстро нажал на восстановление пароля, вы сохранили токен восстановления, письмо в очередь, потом токен перетерся новым, еще одно письмо в очередь. Если очередь затупила, то в зависимости от того как реализован метод отправки письма, пользователь может получить либо два письма с разным токеном (первый из них уже не будет работать), либо с самым свежим.

Вообще 99% необычного поведения DJ проявляется, если очередь не успевает обрабатываться, поэтому ее обязательно нужно мониторить. А так можно пользоваться. Работает.

Tweet