Hi, I think I see where you’re going with this; TLDR is I haven’t had any experience with such a setup and I’m sorry I can’t be of more help here.

But perhaps the other examples you mentioned are not directly comparable with this use case:

• Cowboy / NGINX: HTTP is stateless, so shutting the server down should not impact your business other than availability of that node during restarts (like when deploying)
• ETS / Redis: I assume that since you mention ETS and not DETS data stored there is transient (eg. like a cache) and you would not care about them being lost, so again node restarts should not have too much of an impact on your business other than perhaps minor hiccups while the caches are warmed up

But I’m not sure what guarantees one should expect from an in-proc RabbitMQ instance that maybe restarted at any time. Because in that case that would probably mean that you do not care about messages being lost on restarts, which is perhaps valid in IOT scenarios but then you might not need to carry around RabbitMQ as a dependency. If you do care about preserving messages, then you’d need to provide access to some type of permanent storage (eg. disk) for your nodes, which can be pretty limiting when deploying/scaling containers for example, and would be better off perhaps having a stable RabbitMQ VM / cluster that you’d setup once and then forget about it.

Anyway, sorry for the rant. I hope someone else here who has more experience in this matter can chime in.