Producteur/Consommateur — le découplage asynchrone

Le producteur envoie, le consommateur traite — sans attendre l'un l'autre. La queue est le tampon.

Imagine une boulangerie : le boulanger fabrique des croissants et les pose dans la vitrine. Les clients viennent les prendre quand ils veulent. Le boulanger ne les attend pas. C'est exactement le modèle producteur/consommateur.

Le découplage est la propriété centrale : producteur et consommateur n'ont pas besoin de s'exécuter en même temps. Si le consommateur tombe, les messages s'accumulent dans la queue. Quand il revient, il reprend là où il s'était arrêté.

Cas d'usage typiques :

• Envoi d'e-mails : la requête HTTP renvoie immédiatement, l'e-mail est envoyé en arrière-plan.
• Traitement d'images : l'upload se termine vite, le redimensionnement prend du temps — on délègue.
• Synchronisation de données entre microservices : chaque service publie ses événements sur une queue centrale.

Queue, Pub/Sub, Topic — les patterns de distribution

Work queue (1 message, 1 consumer), Pub/Sub (1 message, N consumers), Topic routing (messages routés par clé).

Tous les systèmes de messaging ne distribuent pas les messages de la même façon. Trois patterns couvrent l'essentiel des besoins.

Garanties de livraison — at-most, at-least, exactly-once

Trois niveaux de garantie, trois niveaux de complexité — comprendre lequel tu as vraiment.

Quand on parle de garanties de livraison, on parle de ce qui se passe en cas de panne — réseau coupé, consumer qui crashe, broker qui redémarre. Il existe trois niveaux.

En pratique, at-least-once + consommateur idempotent est le compromis le plus courant. Exactly-once coûte cher en latence et complexité.

ACK, NACK et Dead Letter Queue

L'ACK confirme le traitement. Le NACK signale l'échec. La DLQ recueille les messages qui ne passent pas.

Le mécanisme d'ACK est ce qui distingue at-least-once de at-most-once. Sans ACK, le broker supprime le message dès qu'il l'envoie — si le consumer crashe entre la réception et le traitement, le message est perdu.

// RabbitMQ — PHP AMQP lib
$channel->basic_consume(
    'ma-queue',
    '',       // consumer tag
    false,    // no_local
    false,    // no_ack — false = ACK manuel obligatoire
    false,    // exclusive
    false,    // nowait
    function ($msg) {
        try {
            traiter($msg->body);
            $msg->ack();     // succès → broker supprime le message
        } catch (Exception $e) {
            $msg->nack(false); // échec sans requeue → DLQ
        }
    }
);

Configuration d'une DLQ dans RabbitMQ :

// Déclarer la DLQ
$channel->queue_declare('ma-queue.dlq', false, true, false, false);

// Déclarer la queue principale avec pointeur vers la DLQ
$channel->queue_declare('ma-queue', false, true, false, false, false, [
    'x-dead-letter-exchange'    => ['S', ''],
    'x-dead-letter-routing-key' => ['S', 'ma-queue.dlq'],
    'x-message-ttl'             => ['I', 60000], // TTL 60s
]);

Dans Symfony Messenger, la DLQ est gérée automatiquement via le transport failed : les messages qui ont dépassé le nombre de retries sont routés vers ce transport, inspectables avec bin/console messenger:failed:show.

Backpressure — quand les consommateurs ne suivent pas

Si les producteurs sont plus rapides que les consommateurs, la queue explose. Backpressure = le signal qui dit « ralentis ».

Imagine un tuyau d'arrosage branché sur une citerne. Si tu ouvres le robinet plus vite que le tuyau ne peut écouler l'eau, la citerne déborde. C'est exactement la backpressure : le signal que le système envoie en amont pour dire "tu vas trop vite".

Dans les systèmes de messaging, le symptôme est visible : la queue grossit sans arrêt. Solutions :

Dans Node.js streams, la backpressure est intégrée : writable.write() retourne false quand le buffer interne est plein, signalant au producteur de s'arrêter jusqu'à l'événement drain. TCP utilise le même mécanisme via la fenêtre de congestion.

RabbitMQ — exchanges, bindings et routing

Exchange direct, fanout, topic — la flexibilité de RabbitMQ vient de sa séparation entre exchange et queue.

RabbitMQ s'appuie sur le protocole AMQP. Sa flexibilité vient d'une architecture en deux niveaux : les exchanges reçoivent les messages des producteurs, les queues stockent les messages pour les consommateurs. Un binding relie les deux.

// Déclarer un exchange topic et binder une queue
$channel->exchange_declare('events', 'topic', false, true, false);
$channel->queue_declare('billing-events', false, true, false, false);
$channel->queue_bind('billing-events', 'events', 'order.*');

// Publier un message
$msg = new AMQPMessage(
    json_encode(['order_id' => 42]),
    ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]
);
$channel->basic_publish($msg, 'events', 'order.paid');

Durabilité — trois conditions pour qu'un message survive à un redémarrage de RabbitMQ :

• L'exchange doit être déclaré durable.
• La queue doit être déclarée durable.
• Le message doit avoir delivery_mode = 2 (persistent).

Kafka — le log distribué immuable

Kafka ne supprime pas les messages après consommation — il stocke un log partitionné que chaque consumer group lit à son rythme.

RabbitMQ est un broker de messages : il distribue et supprime. Kafka est un log distribué : il stocke et laisse lire. Cette différence fondamentale change tout.

// Consommer depuis Kafka (php-rdkafka)
$conf = new RdKafka\Conf();
$conf->set('group.id', 'billing-service');
$conf->set('auto.offset.reset', 'earliest');
$conf->set('enable.auto.commit', 'false'); // commit manuel = at-least-once

$consumer = new RdKafka\KafkaConsumer($conf);
$consumer->subscribe(['orders']);

while (true) {
    $message = $consumer->consume(10000);
    if ($message->err === RD_KAFKA_RESP_ERR_NO_ERROR) {
        traiter($message->payload);
        $consumer->commit($message); // commit après traitement
    }
}

Propriétés clés à retenir :

• Ordre garanti par partition : les messages d'une même partition sont lus dans l'ordre d'écriture. Pas d'ordre garanti entre partitions.
• Parallélisme = nombre de partitions : si un topic a 6 partitions, on peut avoir au maximum 6 consommateurs actifs par consumer group.
• Replay : comme les messages ne sont pas supprimés, tu peux "rembobiner" l'offset et relire l'historique — utile pour rejouer des événements après un bug.

Prefetch et QoS — éviter de surcharger un consumer

Sans limite de prefetch, RabbitMQ envoie tous les messages au premier consumer disponible — même s'il est déjà débordé.

Sans configuration de prefetch, RabbitMQ applique le round-robin "naïf" : il envoie les messages aux consommateurs à tour de rôle, sans tenir compte de leur charge réelle. Un consumer lent qui a 100 messages non traités peut continuer d'en recevoir de nouveaux.

// Limiter à 1 message en cours de traitement par consumer
$channel->basic_qos(
    0,     // prefetch_size — ignoré par RabbitMQ (toujours 0)
    1,     // prefetch_count — 1 = traiter un message à la fois
    false  // global — false = par consumer, true = par channel
);

Avec prefetch_count=1, Worker A va traiter la majorité des messages puisqu'il est disponible plus souvent. Worker B ne reçoit un nouveau message que quand il a fini le précédent. C'est du load balancing fair.

Dans Symfony Messenger, le prefetch est configuré dans le DSN du transport AMQP :

# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async:
                dsn: 'amqp://guest:guest@rabbitmq:5672/%2f/messages'
                options:
                    prefetch_count: 5

Idempotence — traiter deux fois sans conséquence

Avec at-least-once, ton handler peut être appelé deux fois pour le même message. L'idempotence garantit que ça ne change rien.

Avec at-least-once, ton handler peut être appelé plusieurs fois pour le même message. Un crash après le traitement mais avant l'ACK, une reconnexion réseau, un timeout côté broker — tous ces scénarios entraînent une relivraison.

Stratégies concrètes :

// Chaque message a un ID unique
// généré par le producteur
if ($this->processed->contains($msg->id)) {
    return; // déjà traité, skip
}
traiter($msg);
$this->processed->add($msg->id);

-- PostgreSQL — INSERT ou ignore si doublon
INSERT INTO orders (id, amount)
VALUES (:id, :amount)
ON CONFLICT (id) DO NOTHING;

Bonnes pratiques :

• Message ID unique côté producteur : génère un UUID v4/v7 à la publication et inclus-le dans le message. Ne te fie jamais à un ID généré côté consommateur.
• Table d'idempotence : une table processed_messages(id, processed_at) avec une contrainte d'unicité sur id. L'insert lève une exception si doublon.
• Fenêtre temporelle : si les doublons ne peuvent arriver que dans un délai court (ex. : 24h), nettoie la table d'idempotence régulièrement pour éviter sa croissance infinie.

Synthèse — RabbitMQ ou Kafka ?

Latence vs débit, push vs pull, suppression vs retention — le guide de choix entre les deux.

RabbitMQ et Kafka sont souvent présentés comme concurrents. En réalité, ils répondent à des besoins différents. Le choix dépend de ta question centrale : veux-tu distribuer du travail ou conserver un historique d'événements ?

Points essentiels à retenir :

• Le pattern producteur/consommateur découple temporellement les composants — la queue est le tampon de résilience.
• ACK/NACK et la DLQ sont les deux mécanismes centraux de la fiabilité côté consommateur.
• At-least-once + idempotence est le duo gagnant pour 80 % des cas — plus simple qu'exactly-once.
• La backpressure doit être anticipée à la conception, pas rattrapée en urgence quand la queue explose.
• Le prefetch est le premier levier à ajuster si tu as des workers hétérogènes.