comparison_table.md

• 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	.	.
.	.	.	.
Con	This will create many more delayed_jobs than we currently have - could run into scaling problems (though concurrency might help this)	Needs a cron job to delete events whose jobs have all completed	Event data will be duplicated several times in the delayed_jobs table. Parallel processing may help keep the size of delayed_jobs table down.
Con	.	Event_id index on delayed_jobs could make it slower	.
Con	.	Requires significant hacking of the delayed_job gem which could be difficult or switching to a different background process gem	.