RabbitMQ, Kafka et Redis déplacent tous des messages entre les parties d'un système, ce qui explique qu'ils atterrissent dans la même conversation. Ils reposent sur des modèles différents : RabbitMQ est une file de tâches avec un routage riche, Kafka est un log d'événements persistant que vous pouvez rejouer, et Redis est un stockage en mémoire qui peut faire de la mise en file légère. Bien choisir, c'est faire correspondre le modèle à ce dont vous avez réellement besoin.

RabbitMQ vs Kafka vs Redis en un coup d'oeil

RabbitMQ : un vrai message broker

RabbitMQ brille quand vous avez besoin de routage : les exchanges et les bindings permettent de diffuser un message vers plusieurs files, de router par clé, ou de filtrer par headers, et les consommateurs acquittent chaque message pour que la redélivraison soit précise. C'est le bon choix pour distribuer du travail de fond entre des pools de workers, pour les patterns requête-réponse, et pour tout flux où la logique de routage n'est pas triviale.

Kafka : un log que vous pouvez rejouer

Kafka n'est pas une file ; c'est un log ordonné et persistant que plusieurs consommateurs lisent indépendamment, chacun suivant sa propre position. Comme les messages restent sur une fenêtre de rétention, un nouveau consommateur peut rejouer l'historique, et vous pouvez reconstruire un stockage en aval à partir du log. Ça en fait l'outil de l'event streaming, de l'event sourcing, et pour alimenter plusieurs pipelines analytics ou de recherche depuis une seule source de vérité. Le coût est opérationnel : partitions, réplication, rééquilibrage des consumer groups, et un cluster à faire tourner.

Redis : l'intermédiaire léger

Redis est probablement déjà dans votre stack pour le cache, et Redis Streams ou de simples listes gèrent bien une file de jobs pour beaucoup d'applications. Le driver de queue de Laravel sur Redis, avec Horizon pour la visibilité, est un montage courant et solide. Les limites sont réelles : tout vit en mémoire, la rétention est bornée, et les fonctionnalités de routage et de rejeu des deux autres ne sont pas là. Utilisez-le jusqu'à avoir une raison concrète de ne pas le faire.

Publier de façon fiable : le pattern outbox

Quel que soit le broker choisi, publier un événement dans le même souffle qu'une écriture en base n'est pas atomique : l'écriture peut committer et la publication échouer, ou l'inverse. Écrivez l'événement dans une table outbox à l'intérieur de la même transaction que le changement métier, puis un processus séparé lit l'outbox et publie vers le broker. C'est ainsi qu'on obtient une publication exactement-une sans transactions distribuées.

Avec Laravel

Pour les jobs de fond, la queue intégrée sur Redis plus Horizon couvre l'essentiel des besoins avec presque aucune mise en place. Pour RabbitMQ, un driver de queue communautaire connecte les mêmes classes Job à un backend RabbitMQ. Pour Kafka, des packages existent mais vous intégrez généralement Kafka pour de l'event streaming entre services plutôt que comme file de jobs Laravel, donc vous le produisez et le consommez directement.

Un guide de décision

• ✓Jobs de fond, une poignée de services, pas de besoin de rejeu : queue Redis plus Horizon.
• ✓Routage complexe, distribution de travail entre pools de workers, requête-réponse : RabbitMQ.
• ✓Event streaming, event sourcing, rejeu, plusieurs consommateurs sur une source : Kafka, et prévoyez le budget opérationnel.
• ✓Pas sûr et sur Laravel : commencez par Redis. Passer à RabbitMQ plus tard est un changement de driver ; passer à Kafka est un changement d'architecture que vous faites délibérément.

RabbitMQ, Kafka et Redis résolvent trois problèmes liés mais distincts : distribuer du travail, streamer des événements rejouables, et faire de la mise en file légère. Sur Laravel, commencez par la queue Redis, passez à RabbitMQ quand le routage devient réel, et adoptez Kafka seulement quand l'event streaming fait vraiment partie de votre architecture.