<p>This is a high level question that I am asking for something I am currently architecting and cannot seem to find the exact answer I am looking for.</p>
<p>Scenario:
I have a .Net Core REST API that will be receiving requests from an external application. These requests will be getting pushed into a RabbitMQ instance. These notifications will be thrown to an exchange, then fanned out to multiple queues for multiple consumers.</p>
<p>There is one consumer that I will be responsible for and I am looking for advice on best practices. Ultimately, there will be a REST API that will eventually need to react to these messages being pushed into the queue. This REST API in question is a containerized (Docker) app running on a Kubernetes cluster. It will be receiving a lot of request traffic outside of these notifications (queue messages), making SQL calls, etc.</p>
<p>My question is, should I have an external microservice (hosted service/background service) that subscribes to this queue with the intent of calling into said REST API. Kind of like a traffic cop; routing messages to the appropriate API method based on certain data points.</p>
<p>Or</p>
<p>Would it be OK to put this consumer directly into the high-traffic REST API in question?</p>
<p>Any advice around this? Thanks in advance!</p>

<p>There is no right or wrong. This is the whole dilemma around monolith-microservices and synchronous-asynchronous.</p>
<p>If you are looking at going with microservices and more asynchronous, you can start with these questions:</p>
<ul>
<li>Do you want your system into different codebases?</li>
<li>Do you want to divide responsibilities among different teams?</li>
<li>Do you want to use different languages/projects for the different components?</li>
<li>Do you want some components of the system to respond faster to the user?</li>
<li>Can your app be ok with the fact that one decoupled component may fail completely?</li>
</ul>
<blockquote>
<p>should I have an external microservice (hosted service/background service) that subscribes to this queue with the intent of calling into said REST API. Kind of like a traffic cop; routing messages to the appropriate API method based on certain data points.</p>
</blockquote>
<p>Yes, if you are thinking more on the microservices route and the answer is 'yes' for most of the above questions (and even more microservices related questions not mentioned).</p>
<hr />
<p>If you are thinking more about the monolith route:</p>
<ul>
<li>Are you ok with the same code base shared across the different teams?</li>
<li>Are you ok with a more unified programming language?</li>
<li>Do you want to have a monorepo? (although you can do micro-services with monorepos)</li>
<li>Is the codebase going to be mainly be worked on by a few people who know it really well?</li>
<li>Is it easy to provide redundancy within the app? i.e If one component fails the application doesn't crash.</li>
</ul>
<blockquote>
<p>Would it be OK to put this consumer directly into the high-traffic REST API in question?</p>
</blockquote>
<p>Yes, if your code can handle it and you are more in line with 'yes' on the answers above.</p>
