Leçon 05 · Communication

Sync vs Async : Bloquer ou Déléguer ?

Dans un système distribué, la façon dont vos services se parlent définit la performance perçue par l'utilisateur. Faut-il les faire attendre au téléphone (Synchrone ) ou leur envoyer un SMS (Asynchrone) pour qu'ils vivent leur vie ?

Le Duel : Appel vs Texto

Synchrone (Bloquant)

L'analogie de l'appel téléphonique :
Vous appelez un ami pour une info. Tant qu'il ne répond pas, vous restez l'oreille collée au combiné. Vous ne pouvez rien faire d'autre.
Impact : Le temps s'arrête pour l'appelant.

Bloquant : Le client attend la réponse (Request/Response).
Simple à comprendre et à débugger.

Asynchrone (Non-bloquant)

L'analogie de l'Email / Messagerie :
Vous envoyez un message. Vous posez votre téléphone et allez faire du sport. La réponse arrivera quand elle arrivera (Fire & Forget).
Impact : Vous êtes libéré immédiatement.

Non-bloquant : Le client continue sa vie immédiatement.
Idéal pour les tâches longues (envoi d'emails, génération PDF).

Visualisation des Flux

Diagramme comparant les flux Synchrone et Asynchrone — Haut : Flux Synchrone (Le client attend). Bas : Flux Asynchrone (Le client reçoit un "ACK" immédiat, le travail se fait plus tard).

La Solution Magique : Queues & Workers

Le Pattern "Producer / Consumer"

Comment faire de l'asynchrone proprement ? On ne laisse pas le serveur web faire le travail lourd. On utilise un intermédiaire.

1. Producer (API)

Reçoit la requête

"Message ajouté !"

2. The Queue

(RabbitMQ, SQS, Kafka)

Stocke la tâche en attente

3. Consumer (Worker)

Serveur en arrière-plan

Traite la tâche quand il est libre

Quand choisir quoi ?

Utiliser SYNCHRONE quand...	Utiliser ASYNCHRONE quand...
✔ Le client a besoin de la réponse tout de suite (ex: Login, Recherche Google).	✔ L'action est lente (> 200ms) ou lourde (Traitement vidéo, Analytics).
✔ C'est une opération de Lecture (GET) simple.	✔ Vous voulez lisser un pic de trafic (Load Leveling) pour ne pas crasher votre DB.
✔ La logique transactionnelle est complexe (si étape 2 échoue, étape 1 doit annuler).	✔ Vous n'avez pas besoin de réponse immédiate (Fire and Forget).

En Entretien (System Design)

Le mot-clé magique : "Découplage"

Ne dites pas juste "j'utilise une queue". Expliquez pourquoi.

Problème :"Si mon service de génération de PDF tombe en panne, l'utilisateur ne peut plus commander."

Solution :"Je découple la commande de la facture via une Queue (SQS). Si le service PDF est down, les messages s'empilent dans la queue sans erreur pour l'utilisateur. Les Workers rattraperont le retard une fois le service rétabli."

Flash Quiz

Auto-évaluation

À toi de jouer

Mission : Architecture d'envoi de Newsletter

Vous devez envoyer 1 million d'emails. Si vous faites une boucle `for` en synchrone, votre serveur va timeout après 30 secondes.

Ta mission : Dessine un flux où :
1. L'admin clique sur "Envoyer".
2. L'API répond "OK" en 10ms.
3. Un système de Queue + Workers traite l'envoi en arrière-plan.

Pour les curieux (Bonus)

Webhooks

Comment savoir quand une tâche asynchrone est finie ? Le serveur ne peut pas vous répondre (la connexion est fermée).
Solution : Vous donnez une URL de "Callback" (Webhook). Quand le Worker a fini, il appelle cette URL pour vous dire "C'est prêt !". C'est comme dire au livreur : "Sonne chez moi quand tu arrives".

Event-Driven Architecture

Pousser le concept à l'extrême. Ici, tout est événement.
"Utilisateur inscrit" → Queue → Worker "Email Bienvenue" + Worker "Analytics" + Worker "CRM".
C'est la base des architectures modernes "Reactive" et Serverless (AWS Lambda).