852f6d5e16
**Changements majeurs** : 1. **Suppression ADR-010 (Commandes volant et likes)** : - Contenu consolidé dans Règle 05 (section 5.3) - Raison : ADR-010 était du métier déguisé en architecture - Section "Implémentation Technique" ajoutée à Règle 05 - Pattern correct (addition) vs incorrect (multiplication) 2. **Déplacement ADR-011 → Compliance** : - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md` - Raison : Nature opérationnelle/légale, pas architecture technique - Nouveau dossier `/docs/compliance/` créé 3. **Renumérotation ADR (010-022)** : - Combler les trous de numérotation (010 et 011) - ADR-012→010, ADR-013→011, ..., ADR-024→022 - 22 ADR numérotés en continu (001-022) - Historique Git préservé (git mv) 4. **Mise à jour références** : - Règle 03 : ADR-010 → Règle 05 (section 5.3) - Règle 09 : ADR-010 → Règle 05 (section 5.3) - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour - Incohérence #15 annulée (faux problème : modes séparés) **Résultat** : - ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel) - ✅ Documentation compliance séparée - ✅ Numérotation ADR continue sans trous - ✅ Single Source of Truth (pas de redondance) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
# ADR-001 : Langage Backend
|
|
|
|
**Statut** : Accepté
|
|
**Date** : 2025-01-17
|
|
|
|
## Contexte
|
|
|
|
RoadWave doit gérer 10M d'utilisateurs avec des connexions concurrentes massives pour le streaming audio géolocalisé.
|
|
|
|
## Décision
|
|
|
|
**Go** avec le framework **Fiber**.
|
|
|
|
## Alternatives considérées
|
|
|
|
### Comparatif synthétique
|
|
|
|
| Option | Conn/serveur | P99 latency | Simplicité | Écosystème RoadWave |
|
|
|--------|-------------|------------|------------|------------|
|
|
| **Go + Fiber** | 1M+ | 5-50ms | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
|
|
| Rust + Tokio | 2M+ | 2-20ms | ⭐⭐ | ⭐⭐⭐ |
|
|
| Node.js | 100-500K | 10-100ms | ⭐⭐⭐⭐ | ⭐⭐⭐ |
|
|
| Elixir/Phoenix | 2M+ | 5-50ms | ⭐⭐⭐ | ⭐⭐ |
|
|
|
|
## Justification
|
|
|
|
### Pourquoi Go plutôt que Rust ?
|
|
|
|
Rust offre meilleures performances absolues (2M conn/serveur vs 1M, 0 GC pauses) mais **Go gagne sur le plan startup** :
|
|
|
|
1. **Time-to-market critique** : MVP en 8 semaines vs 12+ pour Rust
|
|
- Courbe d'apprentissage borrow checker = grosse friction pour juniors
|
|
- Temps compilation + refactoring : 30-60s vs 1-2s Go
|
|
- Recrutement moins onéreux (€35-50K junior Go vs €50-70K Rust)
|
|
|
|
2. **Écosystème production-ready pour RoadWave** :
|
|
- **WebRTC** : pion/webrtc (mature) vs webrtc.rs (naissant)
|
|
- **Tests BDD** : Godog/Gherkin natif en Go, pas d'équivalent Rust
|
|
- **PostgreSQL + PostGIS** : pgx (excellent) vs sqlx (bon mais moins mature)
|
|
- **Zitadel/OAuth2** : clients Go stables vs Rust émergents
|
|
|
|
3. **Performance suffisante pour 10M users distribués** :
|
|
- 1M conn/serveur = 10 serveurs max pour pics
|
|
- GC pauses (10-100ms) acceptable avec stratégie multi-région
|
|
- Scaling horizontal plus simple que vertical
|
|
|
|
4. **Tooling natif** :
|
|
- pprof intégré (CPU, mémoire)
|
|
- race detector systématique
|
|
- Cold start ~10ms (vs ~50ms Rust)
|
|
- **Scalabilité future** : Excellent support Kubernetes (migration prévue à 100K+ users, voir [ADR-015](015-hebergement.md#roadmap-infrastructure))
|
|
|
|
**Note importante** : Kubernetes n'est **pas utilisé en MVP** (Docker Compose sur VPS suffit pour 0-20K users). Go est choisi **principalement** pour sa **simplicité**, son **écosystème mature** et ses **performances concurrentielles**. Le support K8s est un **bonus** pour la scalabilité future, pas la raison principale du choix.
|
|
|
|
### Quand Rust aurait du sens
|
|
|
|
- Si concentrations d'1M+ connexions sur serveur unique (cas rare RoadWave)
|
|
- Si p99 latencies en prod > 100ms deviennent bottleneck (après Growth phase)
|
|
- Si refonte majeure planifiée anyway
|
|
- Stratégie possible : réécrire services hot (WebRTC, HLS streaming) en Rust à phase Scale
|
|
|
|
## Conséquences
|
|
|
|
- Formation équipe sur Go si nécessaire
|
|
- Utilisation des bibliothèques : Fiber (HTTP), pgx (PostgreSQL), rueidis (Redis)
|
|
- Monitoring GC pauses en production (cibler < 20ms p95)
|
|
- Potential migration partielle à Rust pour services critiques post-Series A
|
|
|
|
**Librairies** : Voir [ADR-018](018-librairies-go.md) pour stack complet (16 librairies validées)
|