Messaging Brokers

RabbitMQ eccelle su routing flessibile e code intelligenti; Kafka su log distribuito, retention e rilettura per stream processing.

Approfondimento

Definizioni, contesto e collegamenti tra concetti — leggi prima del palcoscenico interattivo se parti da zero.

Perché esistono prodotti diversi

I broker risolvono problemi leggermente diversi. RabbitMQ nasce come broker generalista con routing flessibile (exchange, binding, routing key), code per consumer, TTL, DLX: ottimo per workload operativi e workflow variabili.

Apache Kafka è un log partizionato distribuito: retention lunga, replay, consumer groups, stream processing. Eccelle quando tratti il flusso come sorgente di verità operativa o analytics e quando ordini per chiave dentro la partizione.

Come orientarsi nella scelta

Chiediti: serve ordinamento stretto per chiave? serve replay storico massiccio? quanto è importante il routing complesso verso molte code? quanto è maturo l’operating model (on-call, runbook, monitoring lag)?

Nel browser non esporre mai credenziali del broker: passa da API gateway, SSE o WebSocket autenticati. Il modulo mostra differenze concettuali; in produzione dimensiona partizioni, retention e policy di sicurezza.

Palcoscenico

Job variabili, TTL, routing verso team diversi

RabbitMQ

5/5

Exchange + binding granulari, DLX, priorità e code per consumer sono il pane quotidiano delle code operative.

Apache Kafka

3/5

Si può fare, ma spesso paghi complessità dove un broker classico è più immediato.

Contratto e codice

Schema JSON basato su CloudEvents 1.0, poi snippet server e client.

{
  "specversion": "1.0",
  "source": "/orders-service",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "time": "2026-05-13T12:00:00.000Z",
  "datacontenttype": "application/json",
  "type": "com.example.infra.broker.choice",
  "data": {
    "rabbit": { "strengths": ["routing", "dlx"] },
    "kafka": { "strengths": ["log", "replay", "consumer groups"] }
  }
}