Architecture microservices pour un service de messaging scalable

Un service de messaging qui envoie 100 000 messages par jour ne se conçoit pas comme un monolithe. Au-delà de 10 000 messages/jour, la scalabilité horizontale, la résilience et la maintenance imposent une architecture microservices. Voici comment concevoir un backend messaging robuste pour WhatsApp, SMS et email.

Découpage en services

Une architecture éprouvée sépare cinq domaines fonctionnels :

• Message Ingestion Service : reçoit les requêtes API des clients, valide, dépose dans une queue.
• Routing Service : décide du canal (WhatsApp prioritaire, SMS fallback) selon la politique de l'expéditeur et l'état du destinataire.
• Channel Adapters : un service par canal (WhatsApp Cloud API, agrégateur SMS marocain, provider email SMTP). Chaque adapter gère les spécificités de son fournisseur.
• Status Service : consomme les webhooks des fournisseurs, met à jour l'état des messages (queued, sent, delivered, read, failed).
• Analytics Service : agrège les métriques (latence, taux de livraison, coûts) et alimente les dashboards.

Le rôle de la queue

Un bus de messages (Kafka, RabbitMQ, AWS SQS, Google Pub/Sub) est le cœur du système. Il permet :

• Découplage temporel : le service d'ingestion accepte des pics de charge même si les adapters sont saturés.
• Reprise sur panne : un message non livré est reconsommé après restart.
• Priorisation : les OTP passent dans une queue high-priority, les campagnes marketing dans une queue standard.
• Scalabilité horizontale : ajouter des consumers sans toucher au producteur.

Idempotence et exactly-once

Un piège classique : envoyer deux fois le même OTP à cause d'un retry. Solution :

1. Client fournit un idempotency-key unique par requête.
2. Service d'ingestion vérifie dans Redis si la clé a déjà été traitée.
3. Si oui, retourne la réponse précédente sans réenvoyer.
4. TTL de la clé : 24h suffit pour la majorité des cas.

Rate limiting et quotas

WhatsApp Cloud API impose des rate limits par numéro (fonction de la note qualité Meta) et par compte. Le Routing Service doit connaître ces limites et distribuer les messages sur plusieurs numéros si nécessaire. Un token bucket par numéro (implémenté en Redis) fait le job.

Observabilité

Instrumenter chaque service avec :

• Traces distribuées (OpenTelemetry, Jaeger) pour suivre un message de l'ingestion à la livraison.
• Métriques Prometheus : latence P50/P90/P99 par canal, taux d'erreur, débit.
• Logs structurés (JSON) avec un correlation-id partagé.

Hébergement au Maroc

Pour les clients soumis à la conformité réglementaire et devant garder les données sous juridiction marocaine, des solutions existent : N+ONE (Casablanca), Datacenter Maroc, hébergement souverain des ministères. Attention : WhatsApp Cloud API elle-même est hébergée aux États-Unis par Meta, donc le seul contrôle porte sur votre backend et vos logs.

Conclusion

Une architecture microservices bien pensée permet à un service de messaging marocain de scaler de 10 000 à 10 millions de messages/jour sans réécriture. Les investissements clés : bus de messages, idempotence, rate limiting par numéro, observabilité complète et respect des contraintes conformité réglementaire.