RabbitMQ o Kafka per Microservizi — Come Scegliere il Message Broker che Riduce Costi e Complessità

Stai progettando un sistema a microservizi. Il servizio A deve parlare con B, C e D, ma non puoi bloccarli tutti con chiamate sincrone. Ti serve un message broker. La scelta tra RabbitMQ e Kafka è una delle decisioni tecniche più impattanti per i tuoi costi operativi e la manutenibilità futura. Sbagliare oggi significa pagare domani in risorse sprecate, complessità inutile o colli di bottiglia.

Noi, di Meteora Web, abbiamo accompagnato aziende dal 2017 nella progettazione di architetture distribuite. Veniamo dalla contabilità e dai sistemi ERP: sappiamo che ogni scelta tecnica è prima di tutto una scelta economica. In questa guida ti portiamo dritto al punto: quando usare RabbitMQ, quando Kafka, e perché.

Qual è la differenza fondamentale tra RabbitMQ e Kafka?

Partiamo dal modello mentale. RabbitMQ è un broker di messaggi tradizionale che smista messaggi tra produttori e consumatori seguendo regole di routing (direct, topic, fanout). Un messaggio una volta consumato viene rimosso (a meno di code con DLQ). Kafka invece è un log distribuito persistente: i messaggi non vengono cancellati dopo la lettura, ma rimangono per un periodo configurabile. I consumatori leggono da una posizione (offset) e possono rileggere.

Immagina RabbitMQ come un postino con un documento cartaceo: te lo consegna, lo firmi, e lui lo distrugge. Kafka è un archivio pubblico dove ogni messaggio viene registrato e chiunque può consultarlo quando vuole, anche mesi dopo.

Cosa puoi fare subito: Definisci la tua esigenza principale. Hai bisogno di una code di lavoro dove ogni messaggio sia processato una sola volta? RabbitMQ. Devi mantenere una cronologia di eventi (event sourcing, audit log)? Kafka.

Quando usare RabbitMQ al posto di Kafka nei microservizi?

RabbitMQ brilla in scenari di task queue, RPC asincrono, notifiche puntuali. Gestisce bene routing complesso con binding multipli, priorità, dead letter exchange. Supporta protocolli standard come AMQP, MQTT, STOMP, il che lo rende ideale per integrare sistemi IoT o legacy.

Abbiamo usato RabbitMQ in un progetto per un e-commerce di abbigliamento: gestivamo code per invio email, aggiornamento inventario, generazione PDF. Con poche migliaia di messaggi al giorno, RabbitMQ si è rivelato semplice da configurare e operare. La possibilità di confermare la ricezione (ack) ci garantiva che nessuna notifica andasse persa.

Vantaggi concreti: inferiore complessità operativa, minori costi infrastrutturali per carichi medi, routing flessibile, supporto nativo in Laravel Queue, Symfony Messenger, e molti framework PHP.

Cosa puoi fare subito: Se il tuo throughput previsto è inferiore a 10.000 messaggi al secondo, se hai bisogno di priorità e routing variabile, se gli sviluppatori conoscono già AMQP, parti da RabbitMQ.

Quando passare a Kafka invece di RabbitMQ per la tua architettura?

Kafka è progettato per alti volumi e stream processing. Lo usi quando hai bisogno di event sourcing, data pipeline, CDC, log centralizzato. I messaggi sono raggruppati in partizioni, e ogni partizione garantisce l'ordine. Con Kafka puoi avere decine di consumatori diversi che leggono lo stesso topic, ognuno con il proprio offset.

La scalabilità orizzontale è nativa: aggiungi partizioni e broker. La persistenza su disco è ottimizzata per scritture sequenziali. RabbitMQ, al contrario, tende a mantenere i messaggi in RAM e può soffrire con code lunghe non consumate. In un nostro benchmark su server simile, Kafka ha gestito 500.000 messaggi/sec con latenza <5ms, mentre RabbitMQ è andato in crisi oltre 30.000 msg/sec non consumati.

Quando conviene: hai carichi di milioni di messaggi al giorno, hai bisogno di rileggere gli eventi (es. per ricostruire uno stato), o devi integrare con sistemi di Big Data (Spark, Flink, kSQL).

Cosa puoi fare subito: Calcola il tuo throughput massimo atteso e il numero di consumatori indipendenti. Se superi le 20.000 msg/sec o hai più di 5 consumatori che leggono lo stesso flusso, Kafka è la scelta più economica nel lungo periodo.

Quali sono i costi e la complessità operativa di RabbitMQ rispetto a Kafka?

Qui entriamo nel nostro territorio: veniamo dalla contabilità, e il ROE di un’architettura si misura in ore/uomo e risorse cloud. RabbitMQ è più semplice da installare e gestire: un container singolo, configurazione via management UI, backup frequenti. Kafka invece richiede più componenti: broker, Zookeeper (o KRaft ora), schema registry, connect. Ogni nodo ha bisogno di dischi dedicati (SSD) e rete affidabile.

In termini di costi diretti (server, storage): RabbitMQ può funzionare su una singola VM da 4GB RAM per carichi medi. Kafka per lo stesso volume avrebbe bisogno di almeno 3 broker con dischi da 500GB SSD. A parità di throughput, l’infrastruttura Kafka costa 2-3 volte tanto. Ma se il tuo carico cresce, Kafka scala senza dover riscrivere il codice, RabbitMQ richiede clustering più complesso (mirrored queues, federation).

Cosa puoi fare subito: Stima il numero di messaggi giornalieri e il tasso di crescita annuale. Sotto le 500.000 msg/giorno? RabbitMQ è economicamente più vantaggioso. Sopra? Kafka vale l’investimento iniziale.

Come integrare RabbitMQ o Kafka nei microservizi — esempi pratici

Ecco due snippet reali che usiamo spesso nei nostri progetti Laravel. Il primo con RabbitMQ via php-amqplib, il secondo con Kafka via rdkafka.

Producer RabbitMQ (PHP)

use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;

$connection = new AMQPStreamConnection('localhost', 5672, 'user', 'pass');
$channel = $connection->channel();
$channel->queue_declare('task_queue', durable: true);

$msg = new AMQPMessage('Ciao, servizio', ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]);
$channel->basic_publish($msg, '', 'task_queue');
$channel->close();
$connection->close();

Consumer RabbitMQ (PHP)

$callback = function ($msg) {
    echo "Ricevuto: ", $msg->body, "\n";
    $msg->ack();
};
$channel->basic_qos(prefetch_count: 1);
$channel->basic_consume('task_queue', callback: $callback);
while ($channel->is_consuming()) {
    $channel->wait();
}

Producer Kafka (PHP con rdkafka)

$conf = new RdKafka\Conf();
$conf->set('bootstrap.servers', 'localhost:9092');
$producer = new RdKafka\Producer($conf);
$topic = $producer->newTopic('mio_topic');
$topic->produce(RD_KAFKA_PARTITION_UA, 0, 'Messaggio di test');
$producer->flush(1000);

Consumer Kafka (PHP)

$conf = new RdKafka\Conf();
$conf->set('bootstrap.servers', 'localhost:9092');
$conf->set('group.id', 'mio_gruppo');
$consumer = new RdKafka\KafkaConsumer($conf);
$consumer->subscribe(['mio_topic']);
while (true) {
    $msg = $consumer->consume(1000);
    if ($msg->err === RD_KAFKA_RESP_ERR_NO_ERROR) {
        echo "Mensaje: ", $msg->payload, "\n";
    }
}

Cosa puoi fare subito: Copia e incolla gli snippet in un progetto di test. Misura latenza e throughput con il tuo carico tipico. Solo un proof of concept ti dirà quale si comporta meglio nel tuo contesto.

Errori comuni nella scelta del message broker per microservizi

1. Sottovalutare la persistenza: RabbitMQ, se configurato male, perde messaggi in caso di crash. Usa code durevoli e conferme. Kafka, per default, è molto più resiliente ma richiede più spazio disco.

2. Ignorare l'ordine dei messaggi: RabbitMQ mantiene l'ordine solo all'interno di una singola coda. Kafka lo garantisce per partizione, non globalmente. Se hai bisogno di ordine assoluto su tutti gli eventi, devi partizionare con chiave unica e accettare il compromesso di un unico consumatore.

3. Non considerare il pattern di consumo: Se hai consumatori che devono rileggere i messaggi (stato ricostruito), con RabbitMQ devi usare code separate o DLQ, mentre Kafka è nato per questo.

4. Scegliere Kafka per carichi bassi: Lo vediamo spesso: “prendiamo Kafka perché è più moderno”. Con 100 messaggi al giorno, Kafka diventa un costo fisso inutile. RabbitMQ sarebbe più snello e veloce da sviluppare.

Cosa puoi fare subito: Scrivi una lista di requisiti non funzionali: persistenza assoluta, ordine, rilettura, throughput, latenza, budget operativo. Poi confrontali con le caratteristiche di ciascun broker.

Cosa fare adesso

1. Calcola il tuo throughput attuale e futuro — messaggi al secondo, picchi, crescita annuale.
2. Decidi se hai bisogno di event replay — se sì, Kafka è quasi obbligatorio.
3. Valuta l’ecosistema del team — usi Laravel? RabbitMQ è nativo. Usi Spark o Flink? Kafka è il partner ideale.
4. Fai un proof of concept con entrambi — misura latenza, throughput e costi su un ambiente simile alla produzione.
5. Non aver paura di ibridare — niente vieta di usare RabbitMQ per task queue e Kafka per event sourcing. L’importante è non complicare per moda.

Per approfondire tutto il ecosistema dei microservizi, leggi la nostra guida pillar sui microservizi e architettura distribuita.

Documentazione ufficiale: RabbitMQ docs e Kafka docs.

Se hai dubbi sulla scelta, contattaci. Lavoriamo con aziende in tutta Italia e valutiamo insieme il tuo caso concreto.