La plupart des problèmes de scalabilité ne sont pas des problèmes d'infrastructure,ce sont des problèmes de code et d'architecture. Ajouter des serveurs à une application mal optimisée la fait simplement tomber plus vite, à coût plus élevé. Auditer d'abord.

Les 10 points d'audit

• ✓1. Requêtes N+1,utiliser les query logs pour trouver les boucles qui déclenchent une requête DB par ligne. Corriger avec l'eager loading.
• ✓2. Index manquants,EXPLAIN ANALYZE les requêtes les plus lentes. Un index manquant sur une table de 10M lignes est catastrophique.
• ✓3. Travail synchrone dans le cycle de requête,emails, rapports, traitement de fichiers. Déplacer vers des queues.
• ✓4. Pas de cache HTTP,ajouter ETag, headers Cache-Control. Mettre un CDN devant les assets statiques.
• ✓5. Requêtes non bornées,toujours paginer. Un `User::all()` sur 500k lignes est une bombe à retardement.
• ✓6. Stockage de session,les sessions fichier ne scalent pas horizontalement. Utiliser Redis.
• ✓7. Cache de config et routes,avec Laravel : `php artisan config:cache && php artisan route:cache`.
• ✓8. Surcharge de logging,les logs niveau debug en production écrivent des millions de lignes. Passer en ERROR en prod.
• ✓9. Performance de l'injection de dépendances,éviter d'instancier des services lourds dans les constructeurs s'ils ne sont pas toujours utilisés.
• ✓10. Fuites mémoire dans les processus longue durée,profiler les workers de queue et démons sur 24h, pas seulement les cycles requête/réponse.

La règle 80/20 de la performance

80% des problèmes de performance viennent des requêtes base de données. Corriger les requêtes, ajouter des index et implémenter du cache avant de toucher à l'infrastructure. D'expérience, adresser ces trois zones seules permet généralement d'obtenir un gain de débit de 3 à 5x sans serveur supplémentaire.