Quand utiliser AWS SQS dans une architecture cloud moderne

SQS est souvent le premier service AWS qu'une équipe adopte et le dernier auquel elle réfléchit. C'est une erreur : l'endroit et la manière dont vous utilisez SQS déterminent le plafond de fiabilité de tout votre système.

La valeur fondamentale de SQS : le découplage

Un appel direct entre deux services crée un couplage fort : si l'appelé est lent, l'appelant attend ; s'il est indisponible, l'appelant échoue. Une file SQS rompt ce lien. Le producteur écrit un message et passe à autre chose. Le consommateur lit les messages quand il est prêt. Les écarts de capacité, les déploiements et les pannes transitoires cessent de se propager en cascade.

Quand SQS est le bon outil

• Déporter le travail. La requête HTTP se termine en 80 ms, le travail lourd est fait par un worker qui consomme depuis SQS.
• Lisser les pics de trafic. Le Black Friday envoie 10× le trafic normal vers le checkout, et SQS absorbe la rafale pour que les workers traitent à un rythme régulier.
• Retries et isolation des pannes. Les messages en échec partent dans une dead-letter queue, visibles et rejouables.
• Agrégation en fan-in. Beaucoup de producteurs, un seul pool de consommateurs, concurrence élastique.

Quand SQS est le mauvais outil

SQS est une file, pas un log. Ces besoins appellent un autre service :

• Plusieurs consommateurs indépendants : utilisez un fan-out SNS → SQS, ou EventBridge.
• Un historique ordonné et rejouable : utilisez Kinesis ou MSK (Kafka).
• De l'event sourcing à haut débit (des millions d'événements/s) : Kinesis ou Kafka.
• Un routage basé sur le contenu des événements : EventBridge et ses règles par pattern sont faits pour ça.

Standard vs FIFO

Les files Standard sont peu coûteuses, offrent un débit quasi illimité, et garantissent une livraison at-least-once avec un ordre best-effort. Les files FIFO garantissent un traitement exactly-once et un ordre strict par message group, à 3 000 messages par seconde avec batching (ou 300 sans).

Ne choisissez FIFO que lorsque vous avez besoin d'un ordre strict ou d'une sémantique exactly-once. La plupart des charges de travail peuvent utiliser Standard avec des consommateurs idempotents, ce qui coûte moins cher et va plus loin en montée en charge.

Dead-letter queues : non négociables

Toute file en production doit avoir une DLQ. Sans elle, un message poison pill bouclera indéfiniment, brûlera du CPU et masquera les vraies pannes. Nos réglages par défaut :

• Max receive count : 5 (ajusté selon le profil d'erreurs).
• Rétention de la DLQ : 14 jours, de quoi déboguer et rejouer.
• Alarme CloudWatch sur une profondeur de DLQ > 0.
• Une Lambda de replay prête à renvoyer les messages vers la file principale après correction.

Visibility timeout : le tueur silencieux

Si un message met plus longtemps à être traité que le visibility timeout, il redevient visible pour les autres consommateurs et se fait traiter deux fois. Réglez le visibility timeout à 6× votre temps de traitement p99 attendu, et renouvelez-le avec ChangeMessageVisibility pour les jobs longs.

// Python consumer renewing visibility during a long task
import boto3, time
sqs = boto3.client('sqs')

def process(msg, queue_url):
    receipt = msg['ReceiptHandle']
    # ... start long job ...
    for _ in range(10):
        time.sleep(30)
        sqs.change_message_visibility(
            QueueUrl=queue_url, ReceiptHandle=receipt, VisibilityTimeout=60)
    # ... finish, then delete ...
    sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=receipt)

Associer SQS et Lambda

Lambda dispose d'une intégration SQS native, mais les réglages par défaut sont piégeux. Ajustez la fenêtre de batching maximale et la taille de batch au débit de votre consommateur. Activez la réponse partielle par batch pour qu'un message défectueux n'empoisonne pas tout le lot. Utilisez ReportBatchItemFailures.

L'essentiel

1. Utilisez SQS pour découpler, lisser les pics ou isoler les pannes.
2. Utilisez EventBridge, Kinesis ou Kafka quand la charge de travail ne convient pas à une file.
3. Configurez toujours une DLQ. Posez une alarme sur sa profondeur.
4. Dimensionnez le visibility timeout à 6× le temps de traitement p99.
5. N'utilisez FIFO que si vous en avez vraiment besoin.