Microservice architecture - carry message through services when order doesn't matter : <p><strong>Tl;dr</strong>: "How can I push a message through a bunch of asynchronous, unordered microservices and know when that message has made it through each of them?"</p>

<p>I'm struggling to find the right messaging system/protocol for a specific microservices architecture. This isn't a "which is best" question, but a question about what my options are for a design pattern/protocol.</p>

<p><a href="https://i.stack.imgur.com/MbHRf.png" rel="noreferrer"><img src="https://i.stack.imgur.com/MbHRf.png" alt="Diagram"></a></p>

<ul>
<li>I have a <em>message</em> on the beginning queue. Let's say a RabbitMQ message with serialized JSON</li>
<li>I need that message to go through an arbitrary number of microservices</li>
<li>Each of those microservices are long running, must be independent, and may be implemented in a variety of languages</li>
<li>The order of services the message goes through does not matter. In fact, it should not be synchronous.</li>
<li>Each service can <em>append</em> data to the original message, but that data is ignored by the other services. There should be <em>no</em> merge conflicts (each service writes a unique key). No service will change or destroy data.</li>
<li>Once <em>all the services have had their turn</em>, the message should be published to a second RabbitMQ queue with the original data and the new data.</li>
<li>The microservices will have no other side-effects. If this were all in one monolithic application (and in the same language), functional programming would be perfect.</li>
</ul>

<p>So, the question is, what is an appropriate way to manage that message through the various services? I <strong>don't</strong> want to have to do one at a time, and the order isn't important. But, if that's the case, how can the system know when all the services have had their whack and the final message can be written onto the ending queue (to have the next batch of services have their go).</p>

<p>The only, semi-elegant solution I could come up with was </p>

<ol>
<li>to have the first service that encounters a message write that message to common storage (say mongodb)</li>
<li>Have each service do its thing, mark that it has completed for that message, and then check to see if all the services have had their turn</li>
<li>If so, that last service would publish the message</li>
</ol>

<p>But that still requires each service to be aware of all the other services <em>and</em> requires each service to leave its mark. Neither of those is desired.</p>

<p>I am open to a "Shepherd" service of some kind.</p>

<p>I would appreciate any options that I have missed, and am willing to concede that their may be a better, fundamental design.</p>

<p>Thank you.</p>
