Skip to main content

Porque não expor ao cliente | RabbitMQ

  • Porque não expor ao cliente | RabbitMQ

1. Segurança (principal argumento)​

Dar acesso direto ao broker significa:

Problemas críticos:​

  • Exposição de credenciais do RabbitMQ no client

  • Impossibilidade de garantir segredo (secret management)

  • Aumento massivo da superfície de ataque

  • Risco de:

    • publicação maliciosa
    • consumo indevido de filas
    • DoS no broker

Fundamentação arquitetural:​

Em arquiteturas modernas, clientes nunca acessam infraestrutura diretamente, apenas APIs controladas.

Isso está alinhado com o conceito de:

  • isolamento de responsabilidades
  • proteção de boundary de sistema

👉 Em arquiteturas cloud-native, a comunicação externa deve passar por camadas controladas (API Gateway / Backend)

2. Violação de Boundary Arquitetural​

RabbitMQ é:

  • infraestrutura interna
  • parte do event backbone

Clientes desktop são:

  • atores externos (untrusted)

Misturar isso quebra um princípio básico:

❌ Anti-pattern​

Cliente → Broker diretamente

✅ Padrão correto​

Cliente → API → Broker

Isso segue o padrão de Service API / Service Abstraction:

  • o cliente nunca conhece o broker
  • ele conhece apenas um contrato (HTTP/gRPC/etc.)

👉 Esse desacoplamento é essencial para evitar acoplamento forte entre cliente e infraestrutura

3. Escalabilidade e Gestão de Conexões​

RabbitMQ não foi projetado para milhares de clientes edge diretamente.

Problemas práticos:​

  • Cada cliente = conexão TCP

  • Uso elevado de:

    • memória
    • file descriptors
    • CPU no broker

  • Dificuldade de:

    • rate limiting
    • controle de QoS por cliente
    • throttling

Comparação​

AbordagemEscalabilidade
Cliente → RabbitMQBaixa / perigosa
Cliente → API → RabbitMQControlada

👉 Sistemas distribuídos precisam controlar o fluxo e carga de entrada, não expor diretamente o backend

4. Governança e Controle​

Sem uma camada intermediária você perde:

  • autenticação centralizada
  • autorização por contexto de negócio
  • auditoria
  • versionamento de contrato
  • validação de payload

Ou seja: você transforma o RabbitMQ em uma API pública sem governança.

👉 Em EDA, é comum diferenciar claramente:

  • eventos internos
  • interfaces externas

5. Evolução e Manutenibilidade​

Se o client fala direto com RabbitMQ:

  • qualquer mudança em:

    • exchange
    • routing key
    • schema

  • quebra TODOS os clientes

Com API:

  • você abstrai mudanças
  • mantém backward compatibility

👉 Isso reduz acoplamento e melhora evolutividade (característica arquitetural essencial)

6. Modelo recomendado (o que você deve propor)​

Arquitetura correta:​

[Clientes Desktop]
        ↓
   API Gateway / Backend
        ↓
     RabbitMQ
        ↓
    Consumers

Benefícios:​

  • segurança
  • controle de carga
  • governança
  • observabilidade
  • desacoplamento

7. Frase pronta (resposta curta para defender)​

Se precisar resumir em reunião:

"Não expomos o RabbitMQ diretamente porque ele é infraestrutura interna. Isso evita riscos de segurança, garante governança e permite controlar escala e fluxo. Clientes externos devem acessar apenas APIs, não o broker diretamente."