Files

jpgiannetti b6b926b233 docs: résoudre incohérences #13 et #14 (emails + K8s)

Résolution de 2 incohérences MODERATE (reste 1/9) :

#13 - Emails techniques uniquement (ADR-018)
- Périmètre strict : auth, sécurité, modération, RGPD uniquement
- Pas de notifications sociales/marketing/newsletters
- Projection coûts : 93 emails/jour en MVP → gratuit
- Condensé : 112 → 75 lignes

#14 - Kubernetes roadmap clarifiée (ADR-001, ADR-017)
- ADR-001 : K8s = bonus scalabilité future, pas raison principale
- Go choisi pour simplicité, écosystème, performance
- ADR-017 : Roadmap 3 phases avec triggers métriques
  - MVP (0-20K) : VPS + Docker Compose (~14€)
  - Croissance (20-100K) : Scaleway managé (~100€)
  - Scale (100K+) : Kubernetes (~500€)
- Condensé : 137 → 65 lignes

INCONSISTENCIES-ANALYSIS.md :
- 8/9 MODERATE traités (6 résolus, 1 annulé, 1 documenté)
- 1 MODERATE restant : #15 (Unlike Manuel)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2026-02-01 12:19:13 +01:00

3.0 KiB

Raw Blame History

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 :

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)
É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
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
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-017)

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-020 pour stack complet (16 librairies validées)

3.0 KiB Raw Blame History