Module 9
Découplage : SQS et SNS
Files, notifications et fan-out : absorber les pics sans perdre un seul message.
1. SQS : la file d'attente
- Standard : débit quasi illimité, ordre au mieux, au moins une fois. FIFO : ordre strict et déduplication, 300 msg/s (10 000 en batch).
- Visibility timeout : message invisible pendant son traitement ; s'il n'est pas supprimé, il réapparaît. Long polling (jusqu'à 20 s) pour réduire les coûts.
- Dead-letter queue (DLQ) : isole les messages en échec après N réceptions (maxReceiveCount) pour analyse.
- Rétention 1 minute à 14 jours ; chiffrement SSE-SQS ou SSE-KMS ; politiques d'accès.
Pourquoi c'est important : Un flash de commandes écrase vos workers, les requêtes synchrones expirent et des commandes sont perdues sans trace. En plaçant une file SQS devant les traitements et un topic SNS pour prévenir tous les services en parallèle, le pic est absorbé, chaque message est rejoué et la montée en charge ne casse plus rien.
L'analogie qui aide : SQS est la file de la boulangerie avec tickets numérotés : chacun attend son tour sans bousculade, et les ratés vont au comptoir des réclamations (DLQ). SNS est le mégaphone qui annonce une fournée à tous les rayons d'un coup pour déclencher le fan-out vers plusieurs files.
2. SNS : la diffusion
- Modèle publish/subscribe : un message vers N abonnés (SQS, Lambda, HTTP, email, SMS).
- Fan-out : un topic SNS alimente plusieurs files SQS (parallélisme + persistance). Topics FIFO pour l'ordre.
- EventBridge : bus d'événements avec routage par règles (planifié, SaaS, services AWS) ; Step Functions pour orchestrer des workflows ; API Gateway comme porte d'entrée HTTP/REST/WebSocket.
Démonstration pas à pas : Besoin : 50 000 commandes par heure sans perte, avec facturation, stock et notification en parallèle. Étape 1 : un topic SNS reçoit chaque commande et la diffuse en fan-out vers trois files SQS dédiées. Étape 2 : chaque file a une DLQ avec maxReceiveCount à 5 et un long polling de 20 secondes pour réduire les coûts. Étape 3 : les workers consomment, traitent puis suppriment, sinon le message réapparaît après le visibility timeout. Pourquoi pas des appels directs synchrones : le premier service lent fait tout échouer. Pourquoi pas du Standard si l'ordre compte : prenez FIFO avec déduplication.
aws sqs create-queue --queue-name commandes
aws sqs create-queue --queue-name commandes.fifo --attributes FifoQueue=true,ContentBasedDeduplication=true
aws sqs send-message --queue-url https://sqs.eu-west-3.amazonaws.com/1234/commandes --message-body "commande-42"
aws sqs receive-message --queue-url https://sqs.eu-west-3.amazonaws.com/1234/commandes --max-number-of-messages 5 --wait-time-seconds 10
aws sqs purge-queue --queue-url https://sqs.eu-west-3.amazonaws.com/1234/commandes
aws sns create-topic --name alertes
aws sns subscribe --topic-arn arn:aws:sns:eu-west-3:1234:alertes --protocol email --notification-endpoint ops@exemple.fr
aws sns publish --topic-arn arn:aws:sns:eu-west-3:1234:alertes --message "deploiement termine"
aws sqs list-queues
aws sns list-topicsPoints d'examen :
- Pic de charge + pas de perte = SQS devant les workers (découplage).
- Un événement vers plusieurs cibles = SNS fan-out.
- Ordre strict = FIFO (SQS et SNS) ; échecs = DLQ.
- Visibility timeout supérieur au temps de traitement, sinon double traitement.
Pièges classiques : Pic plus aucune perte égale SQS devant les workers, un événement vers N cibles égale SNS en fan-out. Ordre strict et déduplication égale FIFO à 300 messages par seconde, sinon Standard quasi illimité. Réglez le visibility timeout au-dessus du temps de traitement et isolez les poisons dans une DLQ.
À vous de jouer : Des ordres boursiers doivent être traités strictement dans l'ordre et une seule fois. Que choisissez-vous ?
Voir la réponse
Une file SQS FIFO avec ContentBasedDeduplication et un topic SNS FIFO en amont si diffusion. La file Standard autorise doublons et désordre, donc réponse fausse à l'examen.