Event-driven

Une architecture event-driven (orientée événements) repose sur un bus de messages (Kafka, NATS, RabbitMQ, AWS SNS/SQS, Google Pub/Sub) où les services publient des événements (`commande_créée`, `paiement_validé`, `stock_modifié`) que d'autres services consomment, sans connaître l'identité de l'émetteur ni du récepteur. C'est l'inverse du modèle requête/réponse synchrone d'une API REST : ici, l'émetteur ne sait pas qui écoute, et le récepteur traite à son rythme. Le découplage est maximal — on peut ajouter de nouveaux consommateurs (analytics, IA, notifications) sans toucher au producteur.

Les vrais cas d'usage : e-commerce à fort volume (une commande déclenche stock + paiement + email + facturation + analytics, chacun à son rythme), data pipelines (Kafka qui ingère des millions d'événements/seconde), IoT/industriel, fan-out (un événement consommé par 5 systèmes). C'est aussi la colonne vertébrale d'archis microservices à grande échelle, où le couplage synchrone deviendrait fragile. On le retrouve dans la fintech, le retail à l'échelle, et certains secteurs comme la logistique ou l'industrie.

Les revers : debugging complexe (tracer un flux qui passe par 5 topics Kafka), eventual consistency (les données ne sont pas synchronisées instantanément), gestion des échecs (dead-letter queues, replay, idempotence — comme un webhook), et coût (Kafka managé démarre à 500-1 000 €/mois). Pour un SaaS ou un outil métier PME, c'est presque toujours overkill — un monolithe avec des jobs background (BullMQ, Sidekiq) couvre 95 % des besoins. L'event-driven devient pertinent au-delà de quelques milliers d'événements/minute, ou quand l'audit/replay est métier (finance, secteurs réglementés).