Attendre ou traiter plus tard, synchrone et asynchrone
Choisir entre traitement synchrone et file de messages change directement ce que vit l'utilisateur quand un service ralentit. Vous apprenez à trancher étape par étape dans un parcours, à anticiper retards, doublons et échecs, et à décrire dans la spec les états intermédiaires que l'interface doit afficher.
Objectif de la leçon
À la fin de cette leçon, vous serez capable de décider, pour chaque étape d'un parcours, si elle doit être traitée pendant que l'utilisateur attend ou confiée à une file de messages, d'anticiper doublons, retards et échecs, et de spécifier ce que l'utilisateur voit pendant ce temps.
Thèmes abordés
- synchrone et asynchrone
- file de messages
- architecture événementielle
- cohérence à terme
- traitement en arrière-plan
Dans quel module
Structurer le système
Faut-il découper le système, et quand faut-il attendre une réponse plutôt que traiter plus tard ?
Leçons du module
- Monolithe, monolithe modulaire ou microservices
- Attendre ou traiter plus tard, synchrone et asynchrone (cette leçon)
Ce que vous apprendrez dans la formation
Cette leçon fait partie de la formation Lire et challenger une architecture technique
- Lire un schéma d'architecture (niveaux contexte et conteneurs du modèle C4) et y repérer composants, flux, frontières et zones floues.
- Transformer des attentes vagues (« rapide », « fiable », « évolutif ») en exigences non fonctionnelles mesurables, sous forme de scénarios d'attributs de qualité.
- Comparer monolithe, monolithe modulaire et microservices, puis appels synchrones et traitements asynchrones, selon l'équipe, la charge et les conséquences pour l'utilisateur.
- Évaluer les choix de données (source de vérité, transactions, réplicas, cohérence), de montée en charge et de cache, et repérer le goulot d'un parcours.
- Évaluer les dépendances à des services tiers (disponibilité composée, mode dégradé, dépendance au fournisseur) et une décision construire ou acheter.
- Formuler un arbitrage d'architecture, le tracer dans un ADR et traiter la dette technique comme une décision produit.
- Conduire une revue d'architecture de son produit ou d'une proposition, avec dix questions, un registre des risques et des arbitrages explicites.
Formations liées
- Git pour les PM : livrer en équipe sans risquer la prodConfirmé · ~3 h 30 min
- Expliquer comment fonctionne un produit web, du navigateur au serveurTout public · ~2 h 30 min
- Concevoir et tester une intégration API en tant que PMJunior · ~3 h