Scalabilité d'un service de messaging : retours d'expérience

Construire un service de messaging WhatsApp qui tient la charge est un défi d'ingénierie sous-estimé. Tant qu'on envoie quelques centaines de messages par jour, tout va bien. Dès qu'on passe la barre des 100 000 messages quotidiens, avec des pics à plusieurs milliers de messages par minute, les faiblesses architecturales apparaissent brutalement. Retours d'expérience d'équipes marocaines confrontées à cette réalité.

Pourquoi le messaging est un cas de scalabilité particulier

Un service de messaging combine plusieurs contraintes qu'on retrouve rarement ensemble :

• Débit sortant élevé avec rate limits imposés par Meta.
• Débit entrant imprévisible (webhooks de statut, messages utilisateurs).
• Latence critique : un OTP envoyé 10 secondes trop tard est perdu.
• Volume de logs très important à archiver pour l'audit et le debug.

Le pattern de base : file d'attente asynchrone

La première brique est presque toujours une file d'attente entre l'API applicative et l'appel WhatsApp. Les demandes d'envoi sont poussées dans une queue (Redis, RabbitMQ, Kafka, SQS), puis consommées par un pool de workers.

Bénéfices

• Amortissement des pics : l'API reste réactive même sous stress.
• Retry automatique en cas d'échec temporaire.
• Priorisation possible entre catégories (OTP prioritaires sur marketing).

Respecter les rate limits Meta

WhatsApp Business API impose des limites de débit en fonction du tier du numéro. Un nouveau numéro démarre souvent à 1 000 conversations par 24 heures, puis évolue automatiquement selon la qualité et le volume (10k, 100k, illimité).

Le token bucket côté worker

Implémenter un token bucket partagé (par exemple via Redis) permet à plusieurs workers de respecter collectivement le rate limit sans se coordonner explicitement. Chaque envoi consomme un token, le bucket se recharge à un rythme calibré.

Gérer les webhooks de statut

Meta envoie un webhook par changement de statut : sent, delivered, read, failed. Pour 100 000 messages, cela peut représenter jusqu'à 400 000 webhooks entrants. Sans architecture adaptée, l'endpoint webhook devient un goulot d'étranglement.

Bonnes pratiques observées

• Endpoint webhook léger qui se contente d'accuser réception (200 OK) et pousse le payload dans une queue.
• Traitement asynchrone dans un worker dédié, découplé de l'endpoint.
• Idempotence stricte : le même webhook peut arriver plusieurs fois, il faut savoir dédupliquer.

Observabilité indispensable

Sans observabilité fine, impossible de diagnostiquer un problème de scalabilité. Les briques minimales :

• Métriques : Prometheus + Grafana, exposant débit, latence par étape, taux d'erreur.
• Traces distribuées : OpenTelemetry pour suivre un message de l'API jusqu'au webhook final.
• Logs structurés : JSON avec un identifiant de corrélation propagé sur toute la chaîne.
• Alerting : seuils sur les taux d'échec par catégorie, latence percentile 99, backlog de la queue.

Gestion des templates à grande échelle

Avec plusieurs dizaines de templates et plusieurs langues, la validation Meta devient un processus à outiller :

• Versioning des templates dans le code source (git).
• Script CI/CD qui pousse les templates via API et attend la validation.
• Feature flag pour basculer entre versions sans redéploiement.

Optimiser la latence perçue

Pour un OTP, la latence utilisateur est ce qui compte. Quelques optimisations éprouvées :

• Générer le code OTP côté serveur avant même l'appel à l'API WhatsApp.
• Répondre 200 au client applicatif dès la mise en queue, avec un identifiant de suivi.
• Prioriser la queue OTP par rapport aux autres catégories.
• Colocaliser les workers avec un point de présence proche de l'infrastructure Meta.

Retour terrain : les erreurs qui coûtent cher

Trois erreurs récurrentes rencontrées sur des projets marocains :

1. Webhook non idempotent : les statuts sont comptés deux fois, faussant le reporting.
2. Absence de circuit breaker : quand Meta est ralenti, tous les workers restent bloqués en attente.
3. Pas de séparation OTP / Marketing : une campagne marketing sature la queue et fait tomber les OTP critiques.

Sizing d'infrastructure indicatif

Pour un service traitant environ 1 million de messages sortants par jour au Maroc :

• Une dizaine de workers d'envoi selon le langage et la stack.
• Redis en mode cluster pour la queue et le token bucket.
• Postgres ou équivalent pour la persistance longue durée des statuts.
• Un endpoint webhook derrière un load balancer, dimensionné pour ~5 000 req/s en pointe.

Conclusion

Scaler un service de messaging n'est pas qu'une affaire d'infrastructure : c'est un mélange d'ingénierie logicielle rigoureuse, d'observabilité, et de discipline dans la gestion des rate limits imposés par Meta. Les équipes marocaines qui traitent ces sujets méthodiquement construisent des services robustes qui deviennent un vrai avantage compétitif face à des concurrents qui bricolent encore avec des scripts et des tableurs.