---
name: scalability-planner
description: Planification de la scalabilité d'une application ou infrastructure. Se déclenche avec "scalabilité", "scaling", "montée en charge", "millions d'utilisateurs", "haute disponibilité", "scale", "horizontal scaling".
---

# Scalability Planner

## Workflow
1. 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).
2. 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).
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.