Handling multiple events in Event Driven Architecture

Question

Let's say I have

• Service A that publishes Message 1 to be processed by Consumer A
• The same service A that publishes Message 2 to be processed by Consumer B

I need to make sure that consumer B processes Message 2 only after Message 1 has been fully processed. What is the common or best approach to this kind of situation ?

I was thinking that maybe I would need to generate a unique identifier and pass it in both messages and store it in the database so that Consumer A can update the status of the process and Consumer B can look up the status and only starts processing Message 2 after Consumer A has finished, otherwise it would push the message back into the queue. Would that be feasible ?

• Helena: It would be useful if you could explain why message 1 needs to be processed first. While I am sure it can be achieved, it would be even better if this dependency could be removed completely.
• senel34: Consumer A and Consumer B both create different objects, but the object created by Consumer B from Message 2 requires data from a different object created by Consumer A from Message 1. So if message 2 gets processed first, it'll look for the data created from message 1 which hasn't been created yet
• senel34: I should probably add in case it wasn't clear, Consumer A and Consumer B consumes from different queues, Message 1 and 2 have different structures and they both serve their own purpose to create two different objects in two different domains. It's just that one of the object requires data from the other one
• lewislbr: Maybe Consumer A can notify back Service A once processed and then Service A can send to Consumer B?
• senel34: Wouldn't that make the system not event driven anymore ? That would mean Service A needs to wait for Consumer A to finish first and give a response before service A can publish message 2 and send an http response back to the client. I think what the team was trying to achieve is to have the creation process (message 1 and 2) run in the background so the client wouldn't have to wait too long to get a response back. That would require service A to just push the message to the queue and immediately return a response without waiting for anything

Answer 1

Firstly, you cant guarantee order of events being processed. It sounds like you have one of two problems.

1. Your services are dependent on each other - a problem
2. You're misunderstanding the purpose of the events - easily done. An event should be "this happened". Your other services should react accordingly by updating their internal data store. If you have services that rely on other services to be able to fulfil their tasks you need to rethink why and adjust your architecture accordingly. Alternatively, this could be a valid situation, in which case - raise a different event and listen to that.