0

I'm trying to understand what correlation ids are in the AsyncAPI spec https://www.asyncapi.com/docs/specifications/v2.0.0#correlationIdObject

There is a full example dedicated to this, but I still have no idea what's the purpose of this property https://github.com/asyncapi/spec/blob/3470a6386736cf6002846d8eb7535308b79c75e8/examples/correlation-id.yml

I'm interested in:

  • Is this information relevant for the data producer (server) or the consumer (client)?
  • What information can we derive from it?
  • For what practical use case should I use it?
Balázs Édes
  • 13,452
  • 6
  • 54
  • 89

1 Answers1

1

correlationid purpose is to specify where in the message you can find the correlation identifier. Sometimes this information is part of the header, sometimes can be in message payload. So the correlationid prop is to unify the way such information is presented to the API description, it is a place where you specify where exactly identifier is located.

Why would you need it? at all. The main reason for me is always tracing. Correlation Identifier is also known as tracing-id or request-id. Please do call it differently. Basically, this is the id of the event that helps you trace the event in the system, through logs and tracing tools like Jeager and others. So you can trace the flow of the event in the system from point A to Z, to for example identify why it didn't get to Z, where did it stack.

It is also useful in request/reply pattern in event driven architecture. Where producer of the event wants to make sure the event it got in reply is a response from a consumer to this specific event.

Lukasz Gornicki
  • 609
  • 4
  • 12
  • Thank you @Lukasz ! Just so I understand you correctly, the correlationId is not required by tooling, it's optional, and purely for tracing right? So technically it makes no difference if correlationId is present or not, there is enough information for all protocols to figure out what channel to dispatch what message to right? Also when you say headers is this specific to certain protocols? – Balázs Édes Aug 09 '21 at 17:00
  • > the correlationId is not required by tooling it really depends on tooling and what you are using it for. Hard to answer – Lukasz Gornicki Aug 11 '21 at 07:24
  • > So technically it makes no difference if correlationId is present or not, there is enough information for all protocols to figure out what channel to dispatch what message to right You can live without this information, yes. Without correlationID, you can still generate code that knows what to do with the message. But you cannot generate code that knows where in the message (header or payload) you have tracing information that you should pass further, in case you consume a message and pass it further – Lukasz Gornicki Aug 11 '21 at 07:28
  • > Also when you say headers is this specific to certain protocols – Lukasz Gornicki Aug 11 '21 at 07:28
  • > Also when you say headers is this specific to certain protocols not even protocols only, it highly depends on implementation. Some do not send over it in header but in the payload. Look at [these](https://github.com/cloudevents/spec/blob/0b8c5bac2e9f3ecd223acc9159ce1abf96d5e591/primer.md#existing-event-formats) examples. They can be in payload and called differently, like `eventId`. So in AsyncAPI spec you need `correlationId` to specify where someone can find it in the incoming message or where to put it in outgoing message – Lukasz Gornicki Aug 11 '21 at 07:37
  • Awesome thanks very much Lukasz. I was afraid it's a different kind of discriminator for the messages, that's needed for some protocols. – Balázs Édes Aug 12 '21 at 08:47