Architecture de référence : grande échelle / fort trafic
À mesure que le trafic augmente, il existe un bon ordre pour protéger la base : d'abord les leviers simples et peu coûteux, puis les complexes. Cet arbre parcourt pas à pas l'ordre montée en charge verticale → réplica de lecture → sharding, les schémas de cache (cache-aside, write-back), la mise en tampon avec une file + backpressure, le rate limiting, l'isolation de la base avec bulkheads/circuit breakers et la prévention des points chauds. Principe fondamental : gardez pour la fin les décisions difficiles à inverser comme le sharding, et épuisez d'abord les gains peu coûteux.
Où se situe le goulot : une seule instance est-elle saturée, les lectures ou les écritures sont-elles lourdes, ou le trafic est-il en rafales ?
Pour résoudre un problème de montée en charge au bon endroit, identifiez d'abord le goulot. Une seule instance est-elle saturée en CPU/mémoire, les lectures dominent-elles, les écritures atteignent-elles la limite, ou des pics de trafic soudains écrasent-ils la base ? Chaque cas désigne un composant différent.
- Une seule instance est saturée ; je n'ai pas encore essayé les leviers simples
- Les lectures sont très lourdes et en croissance
- Des pics de trafic soudains / une charge en rafales écrasent la base
À quelle étape de montée en charge en êtes-vous : verticale, réplicas de lecture ou sharding ?
La montée en charge suit un bon ordre. La montée en charge verticale (matériel plus puissant) est la première étape la plus simple ; ensuite vous répartissez les lectures sur des réplicas ; ce n'est que lorsqu'un primaire unique ne peut plus absorber les écritures que vous passez au partitionnement horizontal (sharding). Où en êtes-vous ?
- Je n'ai pas encore renforcé le matériel / épuisé l'optimisation de base
- Les écritures tiennent sur une instance, mais je dois répartir la charge de lecture
- Un primaire unique ne peut plus absorber la charge d'écriture
Comment protégerez-vous la base de la charge : mise en tampon, limitation ou isolation ?
Monter en charge ne consiste pas toujours à agrandir la base ; il s'agit souvent de la protéger de la surcharge. Allez-vous lisser les pics d'écriture soudains avec une file, limiter le débit des requêtes entrantes (rate limiting), ou empêcher qu'une seule dépendance fasse tomber tout le système (bulkhead/circuit breaker) ?
- Je veux lisser les pics d'écriture soudains
- Je veux limiter/partager équitablement le débit des requêtes entrantes
- Je ne veux pas qu'une dépendance défaillante fasse tomber tout le système
Recommandation : d'abord montée en charge verticale et optimisation de base
L'étape la moins coûteuse et la moins risquée est la montée en charge verticale : ajouter du CPU/de la RAM/des disques plus rapides et corriger les fondamentaux (index, pooling de connexions, paramètres mémoire). Épuisez ces gains avant des décisions complexes comme le sharding.
Recommandation : répartissez les lectures avec des réplicas de lecture
Les écritures restent sur un primaire unique tandis que le trafic en lecture seule est réparti sur un ou plusieurs réplicas. C'est bien plus simple que le sharding et cela résout la plupart des charges à forte lecture ; le primaire ne sert plus qu'aux écritures et aux lectures critiques pour la cohérence.
Recommandation : sharding (partitionnement horizontal) en dernier recours
Lorsqu'un primaire unique ne peut pas absorber la charge d'écriture, vous découpez les données selon une clé en plusieurs morceaux indépendants (shards) ; chaque shard prend en charge une partie des écritures. C'est puissant mais difficile à inverser ; cela complique les requêtes et transactions inter-shards, c'est pourquoi on le garde pour la fin.
Recommandation : schémas de cache (cache-aside + write-back)
Avec un fort trafic à dominante lecture, vous placez un cache en mémoire (Redis) devant la base et servez la plupart des lectures sans qu'elles n'atteignent jamais la base. Pour les écritures à fort volume, le write-back met les écritures en tampon et les vide vers la base par lots, soulageant le primaire.
Recommandation : mise en tampon avec une file (backpressure)
Pour éviter que les pics d'écriture soudains ne frappent directement la base, vous placez une file durable (par ex. Kafka/une file de messages) entre les deux et consommez les écritures au rythme que la base peut soutenir. La file absorbe le pic ; au lieu d'échouer de façon synchrone, le système fonctionne avec une latence maîtrisée (backpressure).
Recommandation : rate limiting (limiter le débit des requêtes)
En limitant les requêtes entrantes par source (rate limiting), vous empêchez à la fois les abus et la consommation de toutes les ressources par un seul client. Plafonner la charge qui atteint la base rend le système prévisible et équitable.
Recommandation : bulkhead + circuit breaker (isolation)
Pour éviter qu'une dépendance (par ex. une base qui ralentit ou un service externe) ne fasse tomber tout le système, vous cloisonnez les ressources en compartiments (bulkheads) et coupez temporairement les appels vers une dépendance qui échoue sans cesse (circuit breaker). Ainsi, une panne partielle ne se propage pas à tout le système.