I'm dealing with a situation where we have a single message broker that processes around a million messages daily, managed by a platform team. Currently, our application consumes the messaging library through a NuGet package, which forces us to update our dependency and redeploy every time the library is updated by the platform team. I'm wondering if we can shift the RabbitMQ message platform library into a sidecar container. The idea is that when our application starts, the sidecar would connect to the broker, handle the messages, and pass them to our application, which should help minimize our need for frequent NuGet updates.
4 Answers
It seems unusual how closely tied your setup is. Typically, using a message broker is about decoupling components to make management easier throughout their development lifecycles. Your proposed solution isn’t unheard of though; it’s your current issue that seems unconventional. Also, having such a system with those message counts feels a bit off, but I get that it might align with industry trends or specific product needs.
The main goal here is to simplify your application's deployment process. Using a sidecar can help with that, but remember to weigh the trade-offs.
Moving the message queue to a dedicated service could also work. That way, you can manage it independently and lessen the dependency on the library.
Why go with a sidecar? If you're just looking to deploy a RabbitMQ cluster, you might find it easier using the RabbitMQ operator, especially if you're not in need of persistent queues.
Yeah, it’s definitely a strange scenario. On the other hand, implementing a sidecar is doable. At my job, we use sidecars configured to listen for specific queues, process messages, and send results elsewhere. This setup also makes testing straightforward, as you can easily run everything locally without needing the message broker.