- Intermédiaire
- Messagerie et streaming
Où on le retrouve dans les vrais systèmes
-
Workers en arrière-plan
Les workers absorbent le travail lent : e-mails, redimensionnement d'images, rapprochement de paiements. La livraison est au-moins-une-fois : les traitements doivent être idempotents, sinon les doublons produisent deux fois leurs effets.
En production : Celery, Sidekiq, AWS Lambda event source, Kubernetes Jobs
-
File de messages
Une file absorbe les pics : l'API répond dès que le message est stocké, et les workers vident l'arriéré à leur rythme. Les files standard livrent au moins une fois et peuvent réordonner ; les files FIFO gardent l'ordre mais plafonnent le débit. Les messages qui échouent à répétition partent en dead-letter.
En production : Amazon SQS, RabbitMQ, Azure Service Bus, Google Cloud Tasks
-
Prestataire de paiement
Les appels prennent des centaines de millisecondes, une petite part échoue de façon passagère, et le prestataire te limite. Ne débite jamais deux fois : envoie une clé d'idempotence avec chaque requête, réessaie avec backoff, et sors l'appel du chemin de la requête quand c'est possible.
En production : Stripe, Adyen, PayPal, Moneris, Square
-
Prestataire e-mail et SMS
La livraison est lente et peut échouer : envoie depuis des workers en arrière-plan, jamais pendant que l'utilisateur attend. Les prestataires brident les expéditeurs et surveillent les rebonds ; une rafale d'e-mails de réinitialisation peut atteindre la limite.
En production : Amazon SES, SendGrid, Mailgun, Twilio, Postmark
Regarde-le casser, puis répare-le
Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.