Reliability : Failures, Rate Limiting, Observability

Ne t'inquiète pas si ces mots te semblent intimidants — on va tous les expliquer au fil du texte. Dans cette leçon, on apprend à parler en entretien des façons de garder un système stable même quand quelque chose ne va pas : timeouts (arrêter d'attendre une réponse après un certain temps, plutôt que

System Design (concevoir un logiciel capable de servir énormément de monde) c'est comme planifier une ville : routes, entrepôts, feux de circulation et équipes de maintenance — pour que la ville continue de fonctionner sans accroc même aux heures de pointe, quand tout le monde est dehors en même temps.

Fiabilité et observabilité: L'idée centrale de la leçon : comment garder le système fiable (toujours en état de marche) et pouvoir voir ce qui s'y passe. Cela inclut : quand arrêter d'attendre (timeouts), quand réessayer (retries), quand bloquer temporairement pour éviter un effondrement (circuit breakers), comment limiter le nombre de requêtes autorisées (rate limits), et comment suivre ce qui se passe grâce aux metrics (métriques), aux logs (journaux) et au tracing (suivi d'une requête).
Trade-off: Trade-off (compromis) — un choix conscient où l'on gagne une chose et on la paie avec une autre, comme choisir de la restauration rapide plutôt qu'un repas maison : on gagne du temps mais on perd en qualité. En entretien, on explique ce qu'on a gagné et ce que ça a coûté.
Métrique opérationnelle: Une métrique opérationnelle — un chiffre qui montre si la décision fonctionne vraiment une fois le système en vie et au service d'utilisateurs réels (on appelle ça la production). Par exemple : latency (le temps pour obtenir une réponse), error rate (la part des requêtes qui échouent), queue lag (combien de tâches attendent dans la file), cache hit ratio (combien de fois on a trouvé la réponse dans la mémoire rapide), et bien d'autres.