La scalabilité est l'un des sujets les plus mal calibrés en développement : soit on la néglige et l'application s'effondre dès les premiers pics, soit on sur-ingénierie dès le départ et on paie en complexité et en budget pour des problèmes qui n'arriveront peut-être jamais.
L'objectif est de concevoir une application qui tient la charge réelle actuelle et peut évoluer sans réécriture quand la croissance le nécessite. Pas plus, pas moins.
Les vrais goulets d'étranglement d'une application
Dans la majorité des applications web, le goulet d'étranglement est la base de données, pas le code applicatif. Des index manquants, des requêtes N+1 ou un schéma mal conçu limitent les performances bien avant que le serveur applicatif soit saturé.
Avant d'investir dans une architecture distribuée, vérifier que les index existent sur les colonnes de filtre et de jointure, que les requêtes sont optimisées, et que le cache est utilisé là où il apporte de la valeur. Ces optimisations peuvent multiplier la capacité par 10 à 100 sans changer l'architecture.
Scalabilité horizontale vs verticale
La scalabilité verticale (augmenter la puissance du serveur) est la plus simple et la moins chère jusqu'à un certain point. Elle convient pour la majorité des applications web jusqu'à plusieurs millions de requêtes par jour.
La scalabilité horizontale (ajouter des instances derrière un load balancer) est nécessaire quand un seul serveur ne suffit plus ou quand la haute disponibilité est requise. Elle introduit la complexité des sessions distribuées et de la cohérence des états.
Cache : où et comment
Le cache applicatif (Redis, Memcached) est efficace pour les données fréquemment lues et rarement modifiées : profils utilisateurs, configurations, résultats de requêtes coûteuses. Il réduit la charge sur la base de données et améliore les temps de réponse.
Le cache HTTP (CDN pour les assets statiques, cache de réponse pour les endpoints publics) est le premier levier à activer. Un CDN bien configuré peut absorber 80 à 90 % du trafic statique sans toucher les serveurs applicatifs.
Traitement asynchrone et files de messages
Les opérations longues (envoi d'emails, génération de fichiers, appels d'APIs tierces lentes) doivent être traitées en dehors du cycle requête/réponse HTTP. Une file de messages (Redis Queue, RabbitMQ, AWS SQS) permet de déléguer ces traitements à des workers asynchrones sans bloquer la réponse à l'utilisateur.
Cette architecture améliore la réactivité perçue par l'utilisateur et isole les traitements lourds des requêtes interactives, avec la possibilité de scaler les workers indépendamment de l'application principale.