Buduję system rezerwacji w Railsach 4.2, gdzie muszę wysyłać zestaw e-maili do użytkowników w ustalonych odstępach czasu (na przykład, że mają zbliżającą się rezerwację, informację zwrotną po jej zakończeniu, link zmienić/anulować istniejącą rezerwację itp.). Rozejrzałem się i znalazłem this i this, ale staram się zdecydować między podejściami.Architektura systemu dla maili przypominających
Widzę dwa główne sposoby budowania tego systemu.
Używanie systemu kolejkowania, takiego jak delayed_job. Za każdym razem, gdy ktoś robi rezerwację, ustawiamy w kolejce wszystkie wiadomości e-mail na prawidłowy czas, kiedy powinny zostać wysłane.
Pro: Jedna kolejka dla wszystkich wiadomości e-mail. Automatyczna logika ponownej próby.
Con: Tysiące wiadomości e-mail w końcu zostaną umieszczone w kolejce w systemie. Konieczność usunięcia, gdy ktoś anuluje rezerwację (zależne: niszczenie e-maili związanych z nią może być dość łatwe). Nieco bardziej złożona logika, o której godzinie potrzebujemy wiadomości e-mail, aby wyjść.
cron+rakeZadanie uruchamiane w pewnym określonym przedziale czasu (co godzinę? Co piętnaście minut?) I sprawdza, czy wiadomości e-mail muszą wyjść. Uruchamia zapytanie takie jak "Znajdź wszystkie rezerwacje, które są trzy dni od teraz", a następnie wysyła wszystkie e-maile.Pro: Wrzuć wszystko do logiki aplikacji, zmniejsz ilość stanu, którego potrzebujemy do śledzenia.
Con: Należy sprawdzić, które wiadomości e-mail zostały wysłane, co jest koncepcyjnie podobne do tabeli zadań, którą już utworzyliśmy powyżej.
Użyłem drugiego podejścia (ponieważ nigdy nie myślałem o pierwszym podejściu: P), jakoś czuję, że drugie podejście jest bezpieczniejsze i łatwiejsze w zarządzaniu. Opieranie się na opóźnionej pracy nie jest tak bezpieczne, jak proces pracy może spaść i bardziej złożona logika, o której wspomniałeś. – nayiaw