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é.

Go avec le framework Fiber.

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	⭐⭐⭐	⭐⭐

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
- Kubernetes first-class
- Cold start ~10ms (vs ~50ms Rust)

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