Où vivent les données, et quand sont-elles à jour ?
Un chiffre différent selon l'écran, et c'est la confiance des clients qui vacille : savoir où vivent les données évite ce genre d'incident. Cette leçon aide le PM à repérer quelle base fait foi pour une fonctionnalité, à comprendre ce que coûtent réplicas et copies synchronisées, et à préciser la fraîcheur tolérée écran par écran.
Objectif de la leçon
À la fin de cette leçon, vous serez capable de désigner la source de vérité de chaque donnée d'une fonctionnalité, d'expliquer ce qu'une transaction garantit et ce que coûtent les copies (réplicas, caches, données synchronisées), et de spécifier la fraîcheur acceptable et le comportement en cas d'écart.
Thèmes abordés
- source de vérité
- transaction
- réplica en lecture
- cohérence des données
- fraîcheur des données
Dans quel module
Données, charge et dépendances
Où vivent les données, qu'est-ce qui cédera en premier sous la charge, et que se passe-t-il quand un fournisseur tombe ?
Leçons du module
- Où vivent les données, et quand sont-elles à jour ? (cette leçon)
- Tenir la charge, trouver le goulot, décider du cache
- Services tiers, disponibilité composée, construire ou acheter
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