Concevoir l’architecture des systèmes à forte charge — Blog Robosoft

Concevoir pour l’évolutivité horizontale dès le départ

Les systèmes qui évoluent en ajoutant des machines, plutôt que des machines plus grosses, évitent les plafonds rigides. Adapter cela quand un monolithe porte déjà la charge coûte bien plus cher que de le prévoir dès le début.

Découpler ce qui n’a pas besoin d’être synchrone

Les files de messages permettent aux parties lentes ou peu fiables d’un système de tomber en panne sans entraîner tout ce qui y est connecté. Toutes les opérations n’ont pas besoin d’une réponse immédiate, et décider lesquelles en ont besoin est une décision d’architecture centrale.

Prévoir l’échec, pas seulement le succès

À grande échelle, il y a toujours quelque chose qui tombe en panne quelque part : un serveur, une liaison réseau, une dépendance en aval. Les disjoncteurs, les nouvelles tentatives avec temporisation et la dégradation progressive empêchent une panne partielle de devenir une panne totale.

Les pièges courants

L’erreur la plus courante est d’optimiser pour une échelle que vous n’avez pas encore, au détriment de la vitesse de livraison. La deuxième est l’inverse : ignorer totalement la montée en charge jusqu’à ce qu’un incident impose une reconstruction en urgence. La bonne approche consiste à concevoir les points de découpe (où un monolithe pourrait se scinder plus tard, où une file pourrait être insérée plus tard) sans forcément tous les construire dès le premier jour.

Une liste de contrôle pratique

• Chaque composant peut-il être redémarré sans faire tomber tout le système ?
• Une dépendance en aval lente dégrade-t-elle le service proprement, ou provoque-t-elle une réaction en chaîne ?
• Avez-vous un résultat de test de charge de moins de six mois, et pas seulement une supposition ?
• Pouvez-vous ajouter de la capacité sans déploiement, par un simple changement de configuration ?