### Capacidade por Default  

12 mensagens por segundo são 1.000.000 por dia.  
RabbitMQ aguenta de 4.000 a 10.000 mensagens por segundo, para um hardware moderno comum.  
Menos de 1.000 mensagens por segundo é algo simples para o RabbitMQ.  
Você só vai enfrentar gargalos ao usar milhares de queues e clientes,  
caso contrário não terá problemas de performance,  
e não haverá motivos para criar um cluster a não ser por motivos de resiliência.  

A partir de 1.000 mensagens por segundo (86 milhões por dia, 2.5 bilhões por mês),  
você pode começar a analisar o tamanho do cluster para dar mais vazão.  

### Dimensione o cluster pensando no pior
Sempre dimensionar pensando quando ocorrer um erro e houver diversas mensagens de erro.  
Quando cair um broker, como ficará o restante do cluster.  
Se alguns consumidores perderem a conexão, como ficará o cluster.  

### Uso de memória  
Classic queues e classic mirrored queues mantém as mensagens na memória, mas começam a evitar de deixá-las na memória caso a memória fique com pouco espaço.  
Não é possível ficar determinando quando esse comportamento vai ocorrer por ser dinâmico.  
O correto é usar lazy queues caso precise sempre ter memória livre.  
Quorum queues deixam todas as mensagens na memória por defaul, mesmo em circunstancias de baixa memória livre.  
Quando as queues crescerem muito, haverá alarmes de memória, e os publishers podem acabar bloqueados.  
Esse comportamento pode ser alterado com propriedades como `x-max-in-memory-length`, mas isso tem um preço, pois, mas mensagens vão começar a serem recuperadas do disco.  

### Redundância e Escalabilidade  
3 brokers para redundancia  
9 brokers para escalabilidade  
9 brokers com quorum queues com replicator factor de 3  

### Message Size  
mensagens grandes com mais de 1Mb podem causar tráfego na rede e saturar a memória.  

### Adverse Conditions  
Um broker pode desligar por diversos motivos:  
* instalação de um patch do SO  
* falha do disco  
* perda da rede  
* falha na memória  

Um cenário de teste para avaliar um pico de 30.000 msg por segundo durante alguns minutos.  
Uma campanha de marketing muito viral pode levar a um tráfego muito maior que o usual.  
Identificar um ataque, ou falha no sistema que possa causar um pico de mensagens.  

### Testes de Carga (Benchmarks)  
Uma ferramenta seria o PerfTest (load generator)  
Porém com Perftest é um teste sintético, para simular o ambiente o ideal é usar as aplicações em si.