Scalabilité progressive
Statut
Document de cadrage architecture — version initiale.
Principe
DMV doit commencer simple, puis scaler progressivement.
La scalabilité ne doit pas conduire à une architecture complexe trop tôt. Le bon ordre est : mesurer, identifier le goulot, optimiser, puis séparer uniquement si nécessaire.
Axes de scalabilité
| Axe | Première réponse | Évolution possible |
|---|---|---|
| API | Optimisation Laravel, cache, index, workers. | Réplicas ou séparation de workloads. |
| Frontend public | Next.js, cache HTTP, CDN. | ISR/SSG, edge cache, optimisation assets. |
| Backoffice | Vite app statique. | Déploiement séparé, cache assets. |
| Jobs | Supervisor workers. | Files dédiées, workers spécialisés, autoscaling. |
| Base de données | Index, requêtes maîtrisées. | Réplication, partitionnement, archivage. |
| Médias | Compression, formats adaptés. | CDN, stockage objet, traitement asynchrone. |
| IA | Quotas et routing modèles. | Files IA, providers multiples, cache. |
État actuel visible
- API Laravel modulaire.
- Nginx avec rate limiting.
- Supervisor avec workers Redis.
- Cron Laravel scheduler.
- Next.js pour DMV public.
- Vite pour backoffice.
- Jobs planifiés pour boosts et alertes.
Stratégie par étapes
- Stabiliser les contrats API et la qualité des requêtes.
- Ajouter cache sur lectures fréquentes.
- Déplacer les traitements longs en queues.
- Optimiser médias et assets.
- Mesurer latence, erreurs et consommation.
- Séparer les files critiques.
- Répliquer ou isoler certains composants si la charge le justifie.
Scalabilité métier
Les domaines à surveiller :
- mur de la ville ;
- recherche locale ;
- publications et médias ;
- notifications ;
- PlayLoop ;
- statistiques ;
- IA ;
- import ou synchronisations.
Risques
- Optimiser trop tôt sans mesure.
- Laisser les frontends accéder à plusieurs sources non cohérentes.
- Saturer l'API avec des tâches longues.
- Négliger le coût IA.
- Mélanger jobs critiques et jobs lourds dans une même file.