La montée en charge verticale revient souvent à ajouter CPU/RAM. L’horizontale exige coordination, partitionnement, cohérence et plus de travail opérationnel — voici pourquoi c’est plus difficile.
Mise à l’échelle signifie « traiter plus sans s’effondrer ». Ce « plus » peut être :
Quand on parle de mise à l’échelle, on cherche généralement à améliorer un ou plusieurs de ces points :
Tout cela revient à un thème central : monter en puissance (scale up) préserve la sensation d’un “système unique”, tandis que la mise à l’échelle horizontale transforme votre système en un groupe coordonné de machines indépendantes — et c’est la coordination qui fait exploser la difficulté.
La mise à l’échelle verticale consiste à rendre une machine plus puissante. Vous conservez la même architecture de base, mais vous mettez à niveau le serveur (ou la VM) : plus de cœurs CPU, plus de RAM, des disques plus rapides, un débit réseau supérieur.
Pensez-y comme acheter un plus gros camion : un seul conducteur et un seul véhicule, mais qui transporte plus.
La mise à l’échelle horizontale consiste à ajouter plus de machines ou d’instances et à répartir le travail entre elles — souvent derrière un équilibreur de charge. Au lieu d’un seul serveur plus puissant, vous exécutez plusieurs serveurs qui coopèrent.
C’est comme utiliser plusieurs camions : vous pouvez déplacer plus de marchandise, mais vous devez gérer la planification, l’acheminement et la coordination.
Déclencheurs courants :
Les équipes montent souvent en puissance d’abord parce que c’est rapide (upgrader la machine), puis passent à l’horizontal quand une seule machine atteint ses limites ou qu’elles ont besoin d’une disponibilité plus élevée. Les architectures matures combinent généralement les deux : des nœuds plus gros et plus nombreux, selon le goulot.
La mise à l’échelle verticale signifie rendre une seule machine plus puissante (plus de CPU/RAM/disque plus rapide). La mise à l’échelle horizontale signifie ajouter davantage de machines et répartir le travail entre elles.
La verticale paraît souvent plus simple parce que votre application se comporte toujours comme « un seul système », tandis que l’horizontale vous oblige à faire coopérer plusieurs systèmes et à maintenir leur cohérence.
Parce qu’à partir du moment où vous avez plusieurs nœuds, il faut une coordination explicite :
Une seule machine évite beaucoup de ces problèmes distribués par défaut.
C’est le temps et la logique nécessaires pour faire en sorte que plusieurs machines se comportent comme une seule :
Même si chaque nœud est simple, le comportement du système devient difficile à raisonner sous charge et en cas de défaillance.
Le sharding (partitionnement) répartit les données sur plusieurs nœuds pour qu’aucune machine n’ait à tout stocker/servir. C’est difficile car il faut :
Cela augmente aussi le travail opérationnel (migrations, backfills, cartographie des shards).
L’état est tout ce que votre application « se souvient » entre deux requêtes ou pendant un traitement (sessions, caches en mémoire, fichiers temporaires, progression d’un job).
Avec la mise à l’échelle horizontale, les requêtes peuvent arriver sur différents serveurs, donc il faut typiquement un stockage d’état partagé (Redis/bdd) ou accepter des compromis comme les sessions sticky.
Si plusieurs workers peuvent prendre le même job (ou qu’un job est réessayé), vous risquez d’appliquer deux fois la même action (facturation, envoi d’email).
Mitigations courantes :
La cohérence forte signifie que, quand une écriture est confirmée, tous les lecteurs voient immédiatement la nouvelle valeur. La cohérence éventuelle signifie que les mises à jour se propagent avec un délai : certains lecteurs peuvent voir une ancienne valeur pendant un court instant.
Utilisez la cohérence forte pour les données critiques (paiements, soldes, inventaires). La cohérence éventuelle est souvent acceptable pour les données moins sensibles (analytics, recommandations).
Dans un système distribué, les appels deviennent des appels réseau, ce qui ajoute latence, jitter et nouvelles causes de défaillance.
Principes usuels :
La panne partielle signifie que certains composants sont lents ou cassés tandis que d’autres fonctionnent. Le système peut être « up » mais produire des erreurs, des timeouts ou un comportement incohérent.
On conçoit des réponses comme la réplication, les quorums, les déploiements multi-zone, les disjoncteurs (circuit breakers) et la dégradation gracieuse pour éviter que les pannes ne se propagent.
Sur plusieurs machines, les preuves sont fragmentées : logs, métriques et traces sont répartis.
Bonnes pratiques :
