Comment envoyer des codes promo à 1M d'utilisateurs dans une courte fenêtre de temps ?

Question

IT Interview Practice · Accepted Answer

Ne parcourez jamais 1M d'utilisateurs dans un gestionnaire de requête — **répartissez la charge (fan out) via une queue**, limitez le débit à ce que chaque provider peut accepter, rendez chaque envoi **idempotent**, et routez les échecs vers une DLQ pour réessai. L'appel API ne fait qu'enfiler le travail ; les workers réalisent les I/O lentes.

## Architecture

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## Composants et flux

- **Campaign API** écrit la campagne et enfile les jobs — un par utilisateur ou par **batch d'environ 500** pour réduire l'overhead de la queue. Elle répond instantanément ; les 1M d'envois se produisent derrière la queue.
- **Queue (Kafka / SQS)** est le buffer et le log de *replay*. Si les workers crashent, les messages restent en place ; aucun code n'est perdu. Partitionnez par `user_id` pour que l'ordre par utilisateur reste stable.
- **Worker pool** tire les jobs et s'autoscale selon le lag de la queue. Chaque worker : (1) réserve un code promo unique, (2) vérifie une **clé de dedup** `SETNX sent:{campaign}:{user}` dans Redis pour qu'un message redélivré ne provoque jamais de double envoi, (3) passe par un **rate limiter** dimensionné au quota du provider, (4) appelle Email/SMS/Push.
- **Rate limiter** est le point crucial : SendGrid ou Twilio vont vous throttler ou vous blacklister au-delà de leur limite. Un token bucket Redis par provider plafonne le RPS sortant quel que soit le nombre de workers.
- **DLQ** capture les messages poison après N réessais avec backoff exponentiel + jitter, pour qu'une mauvaise adresse ne bloque jamais la campagne.

## Perspective d'entretien

L'examinateur cherche à savoir si vous comprenez le **découplage et la back-pressure**. Une « excellente » réponse nomme la panne précise : sans idempotence, une queue at-least-once plus un réessai équivaut à des utilisateurs recevant trois codes ; sans rate limiter, vous vous auto-DDoS sur le provider et êtes throttlé à zéro. Le piège courant est de faire le fan-out de manière synchrone (« juste un `Promise.all` ») — cela mobilise les connexions, n'a aucun réessai, et perd tout lors d'un déploiement.

## Compromis et pannes

- **At-least-once vs exactly-once** : les queues offrent l'at-least-once à faible coût ; vous obtenez le « effectively once » avec la clé de dedup Redis, non pas avec un broker exactly-once coûteux.
- **Throughput vs limites du provider** : vous pouvez ajouter des workers indéfiniment, mais le quota du provider est le vrai plafond — demandez une augmentation de quota ou un pré-chauffage avant la campagne.
- **Panne** : Redis down → les envois se bloquent (fail closed, ne sautez pas la dedup au risque de doublons). Suivez un compteur par campagne pour pouvoir reprendre, et non redémarrer, après un incident.

Architecture

Composants et flux

Perspective d'entretien

Compromis et pannes

Questions connexes