- Approach A: Remove
Events
table, every time something happens schedule a mulitpurpose job. - Approach B: Remove
Events
table, every time something happens schedule multiple single purpose jobs.
. | Both solutions | Approach A | Approach B |
---|---|---|---|
Pro | No | No duplication of event data. | Makes the events table redundant - we can easily get rid of the table and use the Event classes as POROs |
Pro | Failures and retries can be handled by delayed job. | . | No need to check when events can be deleted |
Pro | Failed jobs can be re-run manually | . | No hacking of delayed job gem required |
Pro | Individual queues would not be necessary | . | . |
. | . | . | . |