File d'attente de messages WhatsApp : RabbitMQ vs Kafka

Lorsqu'une entreprise marocaine passe le cap des quelques milliers de messages WhatsApp par jour, la question de la file d'attente devient critique. Envoyer directement à l'API Meta expose à des limites de rate limiting, des pics de charge, et des risques de perte en cas d'échec réseau. Deux technologies dominent le débat : RabbitMQ et Apache Kafka. Comparatif technique orienté production.

Pourquoi une file d'attente est indispensable

La WhatsApp Cloud API applique des rate limits stricts selon la qualité du numéro et le tier attribué (jusqu'à 1 000, 10 000 ou 100 000 messages business-initiated par 24h). Sans file d'attente, un pic marketing peut saturer votre application et provoquer des erreurs 429 en cascade. Les avantages d'une file :

• Buffering : absorption des pics sans surcharger l'API Meta.
• Retry automatique : gestion des échecs temporaires (5xx, timeouts).
• Découplage : l'application métier ne dépend plus de la latence Meta.
• Traçabilité : historique des envois pour audit et debugging.

RabbitMQ : la robustesse traditionnelle

Points forts

• Modèle AMQP mature : queues, exchanges, bindings bien documentés.
• Faible latence : idéal pour l'OTP où chaque milliseconde compte.
• Acknowledgements fins : garantie de traitement au moins une fois.
• Priorités natives : les OTP passent devant les campagnes marketing.
• Écosystème PHP, Node, Python, Go : bibliothèques stables et éprouvées.

Points d'attention

Le clustering RabbitMQ demande une expertise réelle pour éviter les splits-brain. Le throughput plafonne autour de quelques dizaines de milliers de messages par seconde par nœud — largement suffisant pour l'écrasante majorité des cas WhatsApp Business au Maroc.

Kafka : l'échelle industrielle

Points forts

• Throughput massif : millions de messages par seconde, adapté aux grandes plateformes.
• Rétention longue : replay des événements possible sur plusieurs jours ou semaines.
• Partitionnement : scaling horizontal linéaire.
• Écosystème analytics : intégration native avec Spark, Flink, ClickHouse.

Points d'attention

La complexité opérationnelle est nettement supérieure : Zookeeper (ou KRaft), gestion des offsets, tuning des consumer groups. Kafka excelle pour les flux d'événements plutôt que pour la logique de queue transactionnelle. La latence est légèrement supérieure à RabbitMQ, ce qui peut peser sur les OTP.

Quelle techno pour quel usage WhatsApp ?

Cas 1 : e-commerce jusqu'à ~100k messages/jour

RabbitMQ est amplement suffisant. Setup simple : une queue OTP haute priorité, une queue Utility, une queue Marketing. Retry avec exponential backoff, DLQ (Dead Letter Queue) pour les échecs définitifs.

Cas 2 : banque ou opérateur télécom (~millions/jour)

Kafka devient pertinent pour la rétention et la capacité à replayer des événements en cas d'incident. Un pattern courant : Kafka en amont pour la source de vérité, RabbitMQ ou un worker custom en aval pour appeler l'API Meta avec respect strict des rate limits.

Cas 3 : plateforme multi-tenant BSP

Combinaison des deux : Kafka pour l'ingestion et l'audit, RabbitMQ par tenant pour l'isolation des workloads et la priorisation.

Patterns essentiels quel que soit le choix

• Rate limiter global : token bucket respectant le tier Meta.
• Idempotency key : éviter les doublons en cas de retry.
• Circuit breaker : couper le trafic en cas d'erreurs Meta répétées.
• Metrics Prometheus : temps de traitement, taux d'erreur, backlog.
• SMS Failback : sur échec définitif, publier automatiquement dans la queue SMS.

Hébergement au Maroc ou à l'étranger ?

Pour la latence, un cluster hébergé en Europe (Paris, Francfort) offre un excellent compromis, avec des temps d'aller-retour de 30-50 ms vers Meta. Les offres cloud locales marocaines progressent mais restent limitées en services managés RabbitMQ/Kafka.

Conclusion

Pour la grande majorité des projets WhatsApp Business au Maroc, RabbitMQ reste le choix pragmatique : robustesse, faible latence, écosystème mature. Kafka justifie son coût opérationnel uniquement à très grande échelle ou lorsque le replay d'événements devient un besoin métier. Dans tous les cas, la file d'attente doit être pensée dès l'architecture initiale, avant que le succès ne devienne un problème.