# 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)