ADR-012 : Architecture Backend

Statut : Accepté Date : 2025-01-20

Contexte

RoadWave nécessite une architecture backend évolutive tout en gardant la simplicité opérationnelle pour un MVP. Le système doit supporter une croissance progressive de 0 à 10M utilisateurs.

Décision

Monolithe modulaire avec séparation claire en modules internes.

Alternatives considérées

Architecture	Complexité	Coûts infra	Time to market	Évolutivité
Monolithe modulaire	Faible	Faible	Rapide	0-1M users
Microservices	Élevée	Élevée	Lent	1M+ users
Hybrid (Mono + Workers)	Moyenne	Moyenne	Moyen	100K-5M users

Justification

Simplicité : 1 seul binaire Go, déploiement trivial
Transactions : Communications inter-modules en mémoire (pas de latence réseau)
Debugging : Stack traces complètes, profiling unifié
Coûts : 1 serveur suffit pour 100K users (vs N services)
Refactoring : Modules internes bien séparés facilitent migration vers microservices si nécessaire

Structure modulaire

internal/
├── auth/         # Validation JWT, intégration Zitadel
├── user/         # Profils, centres d'intérêt
├── content/      # CRUD contenus, métadonnées
├── geo/          # Recherche géospatiale, algorithme
├── streaming/    # Génération HLS, transcoding
├── moderation/   # Signalements, workflow
├── payment/      # Intégration Mangopay
└── analytics/    # Métriques écoute, jauges

Chaque module suit : handler.go → service.go → repository.go.

Conséquences

Scaling horizontal : réplication complète du binaire (acceptable jusqu'à 1M users)
Transition vers microservices possible en phase 2 (extraction progressive des modules)
Importance de maintenir découplage fort entre modules (interfaces claires)

1.9 KiB Raw Blame History