Se você sabe que precisa de um cluster, então é hora de pensar em como desenhar esse projeto.

RabbitMQ é um excelente aliado na hora de entregar alta disponibilidade, resiliência, confiabilidade, eficiência e escalabilidade. Mas não basta subir uma instância, e sair usando de qualquer forma.

Um dos cenários mais comuns que já esbarrei em consultorias ou na comunidade, é a falta de atenção por total ignorância, produzindo como efeito, risco.

Na ansia de pegar um exemplo e tentar rodar com base no exemplo, ignoram-se os fundamentos, ignoram-se as boas prática e o entendimento de como RabbitMQ funciona e como consequência, o que está sendo implantado vai falhar, vai perder mensagens.

Será que o RabbitMQ consome demais?

Se você usa RabbitMQ ou pretende usar, é importante saber o que é um ofensor para seu deployment RabbitMQ. Aquilo que fará seu servidor RabbitMQ parar.

Aqui apresento 2 métricas que ajudam a prever e prevenir quedas.

Você já deve ter visto que o RabbitMQ é usado para entregar resiliência, disponibilidade e confiabilidade.

Eu já mostrei isso algumas vezes nos últimos anos.

Talvez já tenha descoberto como pode reduzir a pressão de um volume intenso de trabalho sob seus sistemas, sua infra e seu banco, fazendo com que seja possível tolerar cargas de trabalho vezes maiores do que de fato seu parque consegue tolerar, sem precisar escalar seus sistemas.

Mas afinal, e se o RabbitMQ falhar? O que acontece? Como lidar com isso caso aconteça? Como contornar?

Essa série de posts RabbitMQ Clustering – Publish & Consumer Recovery aborda a criação de clusters, seus principais comportamentos e como aplicações .NET podem se recuperar de falhas com pouco ou nenhum esforço.

Usamos Docker e Docker Compose em exemplos de código que são feitos com C# e .NET 7. Divirta-se.