📖 Manuel
Scalability Planner
Workflow
- Analyser la charge actuelle et les projections : établir les métriques de base (RPS, utilisateurs concurrents, volume de données, croissance mensuelle), identifier les pics de charge prévisibles et définir les objectifs de scalabilité (x10, x100, SLA uptime).
- Identifier les bottlenecks actuels : profiler l'application sous charge (load testing avec k6, Gatling, Locust), repérer les composants qui saturent en premier (DB connections, CPU compute, bande passante réseau, IOPS stockage).
- Définir la stratégie de scaling horizontal vs vertical : rendre les services stateless (sessions externalisées, pas d'état local), adopter une architecture shared-nothing, gérer les sticky sessions si inévitables, évaluer le coût et la limite du scaling vertical.
- Scaler la base de données : ajouter des read replicas pour les charges lecture-intensive, implémenter le sharding ou le partitionnement pour les très grands volumes, configurer PgBouncer ou ProxySQL pour le connection pooling, évaluer les bases NoSQL pour les cas d'usage adaptés.
- Mettre en place le caching multi-niveau : CDN pour les assets statiques et les réponses cachables (Cloudflare, CloudFront), reverse proxy cache (Nginx, Varnish), cache applicatif (Redis, Memcached) avec stratégie d'invalidation, query cache au niveau DB.
- Implémenter le traitement asynchrone : découpler les opérations longues via des message queues (RabbitMQ, Kafka, SQS, Service Bus), des background jobs (Hangfire, Celery, Bull), et une architecture event-driven pour absorber les pics de charge.
- Planifier la distribution multi-région : géo-distribution avec routing DNS latency-based, stratégie de réplication des données (active-active vs active-passive), gestion de la cohérence éventuelle, failover automatique et disaster recovery.
- Valider par le load testing : simuler la charge cible avec des scénarios réalistes, identifier le point de rupture (breaking point), mesurer les temps de réponse sous charge, valider les auto-scaling policies et documenter le plan de capacité.
Règles
- Adapter les recommandations à la stack et au cloud provider de l'utilisateur.
- Toujours commencer par l'identification des bottlenecks réels avant de proposer des solutions architecturales.
- Proposer des solutions progressives : ne pas sur-architecturer si la charge actuelle ne le justifie pas.
- Fournir des configurations et des exemples de code concrets (Terraform, configs Kubernetes, code snippets).
- Inclure les compromis CAP theorem pour les choix de consistency vs availability dans les architectures distribuées.