Quiz d'architecture

Réponse : B

La différence fondamentale réside dans le déploiement indépendant. Chaque microservice peut être déployé, mis à l’échelle et mis à jour sans affecter les autres. Un monolithe se déploie comme une seule unité.

Les monolithes peuvent tout à fait monter en charge (verticalement ou avec plusieurs instances). Les microservices ne sont pas intrinsèquement plus rapides — en réalité, la communication réseau ajoute de la latence.

Réponse : C

Le Dependency Inversion Principle (DIP) établit que :

1. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions.
2. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

En pratique, cela signifie utiliser des interfaces ou des contrats entre les couches, plutôt que des dépendances directes vers des implémentations concrètes.

Réponse : B

Un monolithe (en particulier un monolithe modulaire) est un excellent choix lorsque :

• L’équipe est réduite (< 8 personnes)
• Le domaine n’est pas bien défini (les frontières des services vont changer)
• La vitesse de développement importe plus que la mise à l’échelle indépendante
• Vous ne disposez pas de l’infrastructure pour opérer des systèmes distribués

Les microservices ajoutent une complexité opérationnelle considérable. Si vous n’en avez pas besoin, ne l’ajoutez pas.

Réponse : B

Le Circuit Breaker détecte lorsqu’un service externe est en panne ou répond lentement, et « ouvre le circuit » pour cesser de lui envoyer des requêtes. Cela évite que les threads ne se bloquent en attendant des réponses qui n’arrivent pas, protégeant votre système d’une cascade de pannes.

États du circuit breaker :

• Fermé : tout fonctionne normalement, les requêtes passent
• Ouvert : le service est en panne, les requêtes sont rejetées immédiatement
• Semi-ouvert : une requête de test est autorisée pour vérifier si le service s’est rétabli

Réponse : B

L’Outbox Pattern résout le problème de la double écriture : lorsque vous devez à la fois mettre à jour la base de données ET publier un événement, et que les deux opérations doivent être atomiques.

Au lieu de publier directement vers le broker, vous écrivez l’événement dans une table « outbox » au sein de la même transaction de base de données. Un processus distinct lit la table outbox et publie les événements vers le broker. Si la publication échoue, elle est réessayée. Si la transaction échoue, l’événement n’a jamais été écrit dans l’outbox.

Réponse : C

CQRS (Command Query Responsibility Segregation) sépare le modèle de lecture du modèle d’écriture. Cela permet de :

• Optimiser les lectures avec des modèles dénormalisés
• Mettre à l’échelle les lectures et les écritures de manière indépendante
• Utiliser des bases de données différentes pour chaque modèle

CQRS ne nécessite pas Event Sourcing, bien que les deux soient souvent utilisés conjointement.

Réponse : B

Le backoff exponentiel avec jitter est la stratégie recommandée parce que :

• Backoff exponentiel : chaque nouvel essai attend plus longtemps (1s, 2s, 4s, 8s…), laissant au service le temps de se rétablir
• Jitter : ajoute une composante aléatoire au délai pour éviter que tous les clients ne réessaient au même moment (thundering herd)
• Limite de tentatives : définissez toujours un maximum (3 à 5 tentatives en général)

Un retry immédiat sans limite peut aggraver le problème en surchargeant un service qui est déjà en difficulté.

Réponse : B

Les trois piliers de l’observabilité sont :

• Logs : enregistrements textuels d’événements discrets (ce qui s’est passé)
• Métriques : valeurs numériques agrégées dans le temps (combien, à quelle vitesse)
• Traces : suivi d’une requête à travers plusieurs services (par où elle est passée)

Ensemble, ils permettent de comprendre le comportement d’un système distribué. Les alertes, dashboards et rapports sont des outils qui consomment ces données, mais ne sont pas des piliers en tant que tels.

Réponse : B

La différence est significative :

• 99,9 % (trois neuf) : ~8,7 heures d’indisponibilité par an (~43 minutes par mois)
• 99,99 % (quatre neuf) : ~52 minutes d’indisponibilité par an (~4,3 minutes par mois)
• 99,999 % (cinq neuf) : ~5,2 minutes d’indisponibilité par an

Chaque « neuf » supplémentaire exige un investissement exponentiellement plus important en redondance, monitoring et automatisation. La plupart des applications n’ont pas besoin de plus de trois neuf.

Réponse : C

Le pattern recommandé est le suivant :

1. L’API Gateway valide le token d’authentification (JWT, session, etc.)
2. S’il est valide, il propage l’identité de l’utilisateur (userId, rôles) vers les services internes via les headers
3. Les services internes font confiance à l’identité propagée et appliquent l’autorisation selon leurs règles métier

Valider dans chaque service est redondant et coûteux. Valider uniquement dans le frontend est risqué — le backend doit toujours vérifier.