Os message brokers oferecem dois padrões básicos de distribuição ou estilos de sistema de mensagens:

Sistema de mensagens ponto a ponto:  esse é o padrão de distribuição utilizado em filas de mensagens com um relacionamento de um a um entre o remetente e o destinatário da mensagem. Cada mensagem na fila é enviada somente a um destinatário e é usada somente uma vez. O sistema de mensagens ponto a ponto é chamado quando uma mensagem deve receber uma ação somente uma vez. Exemplos de casos de uso adequados para esse estilo de sistema de mensagens incluem folha de pagamento e processamento de transações financeiras. Nesses sistemas, tanto os remetentes quanto os destinatários precisam de uma garantia de que cada pagamento será enviado uma vez e uma única vez.

Sistemas de mensagens de publicação/assinatura:  nesse padrão de distribuição de mensagens, também chamado de "pub/sub", o produtor de cada mensagem a publica em um tópico e diversos consumidores de mensagens se inscrevem nos tópicos para receber as mensagens. Todas as mensagens publicadas em um tópico são distribuídas para todos os aplicativos inscritos. Trata-se de um método de distribuição de estilo de transmissão, no qual há um relacionamento de um para muitos entre o publicador da mensagem e os consumidores. Se, por exemplo, uma companhia aérea disseminasse atualizações a respeito dos horários de pouso ou status de atraso de seus voos, várias partes poderiam utilizar as informações: equipes de solo executando manutenção e reabastecimento de aeronaves, manipuladores de bagagem, comissários(as) de bordo e pilotos se preparando para o próximo destino da aeronave, e os operadores de painéis informativos notificando o público. Um estilo de sistema de mensagens pub/sub seria apropriado para uso nesse cenário.

Os aplicativos nativos de cloud são desenvolvidos para aproveitar os benefícios inerentes da cloud computing, incluindo a flexibilidade, a escalabilidade e a implementação rápida. Esses aplicativos são feitos de componentes pequenos, discretos e reutilizáveis chamados de microsserviços. Cada microsserviço é implementado e pode ser executado independentemente dos demais. Isso significa que qualquer um deles pode ser atualizado, ajustado em escala ou reiniciado sem afetar outros serviços no sistema. Muitas vezes empacotados em contêineres, os microsserviços trabalham juntos para compreender todo um aplicativo, embora cada um tenha a própria solução, incluindo um banco de dados e um modelo de dados que podem ser diferentes dos demais.

Os microsserviços devem ter um meio de comunicação entre si para operar em conjunto. Os message brokers são um mecanismo usado por eles para criar esse backbone de comunicações compartilhadas.

Os message brokers são frequentemente usados para gerenciar comunicações entre sistemas locais e componentes em cloud em ambientes de cloud híbrida . O uso de um message broker oferece maior controle sobre as comunicações entre serviços, garantindo que os dados sejam enviados com segurança, confiabilidade e eficiência entre os componentes de um aplicativo. Os message brokers podem desempenhar uma função semelhante na integração de ambientes multicloud,  permitindo a comunicação entre cargas de trabalho e tempos de execução que residem em plataformas diferentes. Eles também são adequados para uso na serverless computing, na qual os serviços individuais hospedados em cloud são executados sob demanda de acordo com a solicitação.

As APIs de REST são comumente usadas para comunicações entre microsserviços. O termo Representational State Transfer (REST) define um conjunto de princípios e restrições que os desenvolvedores podem seguir ao construir serviços da web. Qualquer serviço que aderir será capaz de se comunicar por meio de um conjunto de solicitações e operadores sem estado compartilhados e uniformes. A Application Programming Interface (API) denota o código subjacente que, quando em conformidade com as regras de REST, permite que os serviços se comuniquem.

As APIs de REST usam o Hypertext Transfer Protocol (HTTP) para se comunicar. Como o HTTP é o protocolo de transporte padrão da Internet pública, as APIs de REST são amplamente conhecidas, frequentemente usadas e amplamente interoperáveis. No entanto, HTTP é um protocolo de solicitação/resposta, por isso, é melhor usado em situações que precisam de solicitação ou resposta síncrona. Isso significa que os serviços que fazem solicitações via APIs de REST devem ser projetados para esperar uma resposta imediata. Se o cliente que está recebendo a resposta estiver inativo, o serviço de envio será bloqueado enquanto aguarda a resposta. A lógica de tratamento de erro e failover deve ser integrada em ambos os serviços.

Os message brokers permitem comunicações assíncronas entre os serviços para que o serviço de envio não precise esperar pela resposta do serviço de recebimento. Isso melhora a tolerância a falhas e a resiliência nos sistemas nos quais eles estão empregados. Além disso, o uso de message brokers torna mais fácil a ajuste de escala dos sistemas, uma vez que um padrão de sistema de mensagens pub/sub pode prontamente oferecer suporte à mudança de números de serviços. Os message brokers também rastreiam os estados dos consumidores.

Considerando que os message brokers podem oferecer suporte a dois ou mais padrões de sistema de mensagens, incluindo filas de mensagens e pub/sub, as plataformas de streaming de eventos oferecem somente padrões de distribuição do estilo pub/sub. Projetadas para uso com altos volumes de mensagens, as plataformas de streaming de eventos são facilmente escaláveis. Elas são capazes de solicitar fluxos de registros em categorias chamadas tópicos para armazená-los por tempo predeterminado. Ao contrário dos message brokers, as plataformas de fluxo de eventos não podem garantir a entrega de mensagens ou rastrear quais consumidores as receberam.

As plataformas de fluxo de eventos oferecem mais escalabilidade do que os message brokers, mas menos recursos que garantem a tolerância a falhas (como o reenvio de mensagens), bem como recursos limitados de roteamento de mensagens e enfileiramento.

Saiba mais sobre  a arquitetura orientada por eventos.

Um barramento de serviço corporativo (ESB)  é um padrão arquitetônico utilizado algumas vezes em arquiteturas orientadas por serviços (SOAs) implementadas em empresas. Em um ESB, uma plataforma de software centralizada combina protocolos de comunicação e formatos de dados em uma "linguagem comum" que todos os serviços e aplicativos na arquitetura possam compartilhar. Ele pode, por exemplo, converter as solicitações que recebe de um protocolo (como XML) para outro (como JSON). Os ESBs transformam suas cargas úteis de mensagens usando um processo automatizado. A plataforma centralizada de software também trata de outra lógica de orquestração, como conectividade, roteamento e processamento de solicitações.

As infraestruturas ESB são complexas e podem causar problemas durante a integração, além de serem caras. É difícil solucionar problemas em ambientes de produção, eles não são fáceis para ajustar a escala e a atualização é tediosa.

Os message brokers são uma alternativa "leve" aos ESBs, pois fornecem uma funcionalidade semelhante: um mecanismo para comunicações entre serviços, só que mais simples e barato. Eles são adequados para uso nas arquiteturas de microsserviços que se tornaram mais comuns à medida que os ESBs caíram em desuso.

Implementar os message brokers pode atender a uma grande variedade de necessidades de negócios entre os setores de mercado e nos diversos ambientes de computação corporativa. Eles são úteis quando uma comunicação confiável entre aplicativos e a garantia da entrega das mensagens são uma necessidade.

Os message brokers são frequentemente empregados das formas a seguir:

• Operações financeiras e processamento de pagamentos:  é fundamental ter certeza de que os pagamentos são enviados uma vez e uma única vez. Usar um message broker para lidar com os dados dessas transações oferece garantia de que as informações de pagamento não serão perdidas nem duplicadas acidentalmente, além de fornecer prova de recebimento e permitir que os sistemas se comuniquem de forma confiável, mesmo quando as redes intermediárias estão inativas.
  
  
• Processamento e atendimento de pedidos de e-commerce:  para fazer negócios on-line, a força da reputação de sua marca depende da confiabilidade do website e da plataforma de e-commerce. A capacidade dos message brokers de aprimorar a tolerância a falhas e garantir que as mensagens sejam consumidas uma única vez faz deles uma escolha natural para processar pedidos on-line.
  
  
• Proteger dados altamente sensíveis em repouso e em movimento:  tanto para mercados altamente regulados quanto para negócios que enfrentam riscos de segurança significativos, é possível escolher uma solução de sistema de mensagens com recursos de criptografia de ponta a ponta.