mdeniz/ESADO.md

## ESADO.md

      
    Raw
  

              ESADO.md
            
          
    Event System Architectural Design Options

We have choosed 5 possible options that can be possible to implement.
Option 1 – Fully remove the Event representation

No more Event classes, no table needed in the database for storing Event's data.
We will store the data needed inside the DelayedJob payload (doesn’t mean that the event data is stored as right now, just the data needed).
Whenever the event happen jobs are created accordingly to:
A) Multipurpose Jobs: One job that does everything related to the event that happened.
B) Single purpose Jobs: One job per thing to do related to the event that happened.
Option 2 – Single events processed in single purpose jobs

One single event per each single purpose job.
Depending on where we will store the data we have two sub-options:
A) Store data in the Event’s table: We need to modify how DJ behaves to keep reference of the events processed.
B) Store data in the DJ payload: One job per thing to do related to the event that happened.
Option 3 – Batches of events processed in multipurpose jobs

Batches of events per each job.
We will keep the things as they are, but running each job in an independent queue to avoid concurrency.
Summary & Comparative

Summary per option:


Option
1A
1B
2A
2B
3


Number of units of work processed
One
One
One
One
Many


Number of purposes of each job
Many
One
One
One
One/Many


Number of jobs created per event
One
Many
Many
Many
None/Many (CreateJob)


Table to store data in between
DJ
DJ
Event
DJ
Event


Pros/Cons comparative:


Option
1A
1B
2A
2B
3


Multiple jobs of the same kind running
Yes
Yes
Yes
Yes
No


Single failures handler
OBS
DJ
DJ
DJ
OBS


Job failures
DJ
DJ
DJ
DJ
None


Queues
Not needed
Individual queues would not be necessary
Individual queues would not be necessary
Individual queues would not be necessary
Individual queues are mandatory


Copies of event data
1 (DJ's table)
1 x job (DJ's table)
1 time (event's table)
1 time (event's table) + 1 x job
1 time (event's table)


Hacking of DJ
No
No
Yes
No
No


Event representation
No
No
Yes
Yes (PORO classes)
Yes


Cleanup of Events records
No
No
Yes
Yes
Yes
Option	1A	1B	2A	2B	3
Number of units of work processed	One	One	One	One	Many
Number of purposes of each job	Many	One	One	One	One/Many
Number of jobs created per event	One	Many	Many	Many	None/Many (CreateJob)
Table to store data in between	DJ	DJ	Event	DJ	Event
Option	1A	1B	2A	2B	3
Multiple jobs of the same kind running	Yes	Yes	Yes	Yes	No
Single failures handler	OBS	DJ	DJ	DJ	OBS
Job failures	DJ	DJ	DJ	DJ	None
Queues	Not needed	Individual queues would not be necessary	Individual queues would not be necessary	Individual queues would not be necessary	Individual queues are mandatory
Copies of event data	1 (DJ's table)	1 x job (DJ's table)	1 time (event's table)	1 time (event's table) + 1 x job	1 time (event's table)
Hacking of DJ	No	No	Yes	No	No
Event representation	No	No	Yes	Yes (PORO classes)	Yes
Cleanup of Events records	No	No	Yes	Yes	Yes