Aller au contenu principal

Architecture événementielle

Statut

Document de cadrage architecture — vision cible, pas encore implémentée. v1.0 — relu le 2026-05-10.

État actuel

Le code backend actuel ne contient pas de système d'événements Laravel formalisé (Events, Listeners). Les actions métier sont déclenchées de manière synchrone dans les services.

Deux jobs planifiés existent et s'exécutent de manière asynchrone via le scheduler :

  • ExpireBoosts : expire les boosts toutes les heures.
  • ExpireAlertes : expire les alertes Mairie toutes les heures.

Ces jobs représentent une première forme d'asynchronisme, sans architecture événementielle complète.

Vision cible

Une architecture événementielle permettrait de :

  • découpler les modules (ex: une publication créée déclenche une notification, une indexation, un log analytics, sans couplage direct) ;
  • faciliter l'extension sans modifier le code existant ;
  • réduire les temps de réponse des contrôleurs en déplaçant les effets de bord en arrière-plan.

Exemples d'événements cibles

ÉvénementListeners potentiels
PublicationCreatedNotification, indexation, analytics
ActeurRegisteredEmail de bienvenue, onboarding
BoostActivatedFacturation Stripe, log
AlerteCreatedDiffusion PlayLoop, notification citoyenne
DeviceRegisteredLog, notification admin
MemberJoinedEmail d'accueil, mise à jour effectif

Infrastructure asynchrone

Le système de queues Laravel est déjà configuré (QUEUE_CONNECTION=database en production). Cette infrastructure permet d'exécuter des listeners asynchrones sans ajout d'infrastructure.

Redis peut être utilisé comme driver de queue pour des performances supérieures.

Comparaison des approches

ApprocheAvantagesInconvénients
Appels synchrones directsSimple, lisible, testableCouplage fort, temps de réponse impacté
Events Laravel synchronesDécouplage, extensibleToujours bloquant
Events + Queued ListenersPerformance, scalabilitéPlus complexe à déboguer
Message broker (Redis Streams, SQS)Scalabilité maximaleInfrastructure supplémentaire

Points à clarifier

  • Décision d'adopter les Events Laravel ou de rester sur des appels directs.
  • Liste des événements prioritaires à implémenter.
  • Choix du driver de queue en production (database vs Redis).
  • Stratégie de retry et dead-letter pour les listeners échoués.
  • Monitoring des queues (Horizon ou équivalent).