<p>I am creating an architecture for my microservices plateform running over Kubernetes.
My current architecture looks like:
<a href="https://i.stack.imgur.com/mEAjg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/mEAjg.png" alt="Current Architecture" /></a></p>
<p><strong>Description:</strong></p>
<ul>
<li>I use Flask to create an API RESTful.</li>
<li>For my IPC mechanism and Event Driven, I use RabbitMQ.</li>
<li>The microservice contains code for calling a Producer and Consumer RabbitMQ.</li>
<li>When the Flask app is started, a consumer is instancied whithin a child process (with multiprocessing library). The Process is not joined, and not killed during all living state of main app (flask).</li>
<li>The producer is instancied only when a request (POST/PUT) is called.</li>
</ul>
<p>And I was wondering, what if my RabbitMQ crashed :</p>
<ul>
<li>The consumer in the microservice will not longer live because it will raise an exception for connecting to rabbitMQ</li>
<li>The microservice API (FLASK) will continue to live</li>
</ul>
<p>So my question is the following:<br />
<em>Is it a good practice to seperate the consumer process into a independant container ?</em></p>
<p>-&gt; The container will run along side the main app in the same pod.<br />
-&gt; The sidecar consumer will have a liveness endpoint, so if RabbitMQ Crashed again, Kubernetes will start only this container.<br />
-&gt; The sidecar consumer will have access to database to write events.<br />
-&gt; The producer can stay in the main app (flask), more resilient for me.</p>
<p>It is correct to do that ?<br />
<a href="https://i.stack.imgur.com/5Xobw.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/5Xobw.png" alt="Next Architecture" /></a></p>

Achraf Bentabib
<p>Yes, I think that's a good approach, because you rely on Kubernetes to check if that container is up or not (with the liveness probe), instead of doing that from the application.</p>
<p>You can also monitor/alert events like that (containers which are down) using the observability stack of the cluster.</p>
