The-Inevitable-Event-Centric-Book icon indicating copy to clipboard operation
The-Inevitable-Event-Centric-Book copied to clipboard

Problem: Define Correlation/CausationId patterns for Events

Open bartelink opened this issue 4 years ago • 5 comments

bartelink avatar Oct 14 '19 10:10 bartelink

I take correlation to mean things belonging in the same group - I would tend to use this for events that were written in one process (or command handler) where causation means one thing is the reason that another thing happened.

Only causation can build up an arrow of time across streams. I have seen correlation used to mean "these all happened at the same time" but that is not really correct.

MerrionComputing avatar Oct 30 '19 10:10 MerrionComputing

I have seen correlation used to mean "these all happened at the same time" but that is not really correct.

Yes, it's really not correct; stuff with the same correlationId can be separated by months in time I'd venture that the correlationId just defines a logical partition within the system [within which a causation is possible]

bartelink avatar Oct 30 '19 10:10 bartelink

Agreed, Correlation is a grouping of things according to some rule I can correlate, in an event driven system, events based on any attribute combination. E.g I want the number of event in my system per event type, month, year , in order to produce that I would correlate in my read model , all event of a given type happening at a certain month & year.

The most important implicit correlation in an ES system is the stream id

ylorph avatar Oct 30 '19 12:10 ylorph

If I have a certain Process Manager / Sagas in my system . And some instances PM1 , PM2, ... are still alive. All messages emitted by one instance of it , could have as CorrelationId the Id of the instance, and as causationId , the ID of the message that triggered the PM/Saga at a certain point in time

Let's say the following messages type exists :

  • T1, T2, T3, T4

And That the following messages exists:

  • {type=T1, ID=E1, correlationID=E1, CausationID= E1}
  • {type=T2 , ID =E2, correlationID=E2, CausationID= E2}

And That there are 2 ProcessManager/Saga

  • Ids of the PM instances are PM1 , PM2
  • PM1 is triggered by types (T1, T2), emits T3 when it received T1 & T2
  • PM2 is triggered by types (T1, T3), emits T4 when T1 or T3

By running the system: E1 triggers PM1, it waits for E2 E1 triggers PM2, it sends {type=T4, ID=E3, correlationId=PM2, causationId=E1} E2 triggers PM1, it sends {type=T3, ID=E4, correlationId=PM1, causationId=E2} E4 triggers PM2, it sends {type=T4, ID=E5, correlationId=PM2, causationId=E4}

State of the system:

  • {type=T1, ID=E1, correlationId=E1, causationID= E1}
  • {type=T2 ,ID=E2, correlationId=E2, causationID= E2}
  • {type=T4, ID=E3, correlationId=PM2, causationId=E1}
  • {type=T3, ID=E4, correlationId=PM1, causationId=E2}
  • {type=T4, ID=E5, correlationId=PM2, causationId=E4}

By looking at the states of the system only we can says: E5 because E4 because E2 E3 because E1 -> Missing piece : E4 is actually because of E1 & E2, because of the private logic of PM1

E3 , E5 are related by PM2 E4 is related to PM1

Or something like that :headache:

ylorph avatar Oct 30 '19 13:10 ylorph

2 things to take into account : The concepts & one implementation in messaging CorrId & CausId

  • #29
  • #30

ylorph avatar Oct 31 '19 06:10 ylorph