Architecture événementielle

Des services qui se parlent sans perdre d'événement

Une messagerie fiable entre vos services, sans perte ni doublon visible, et des interfaces informées en temps réel.

Les problèmes que nous réglons

  • Des événements perdus quand un service plante entre l'écriture en base et la publication.

  • Le même message traité deux fois : stock réservé en double, e-mail envoyé deux fois.

  • Une topologie RabbitMQ qui grossit à chaque nouveau cas d'usage.

  • Des contrats de messages qui cassent en production alors que les tests passaient.

  • Des interfaces qui interrogent le serveur en boucle pour voir un changement.

Ce que nous mettons en place

  • Une topologie simple : une exchange, une queue par service consommateur.

  • Le pattern outbox côté émetteur, l'idempotence côté consommateur.

  • Des contrats versionnés : JSON Schema, DTO et tests de non-régression.

  • Une gestion des erreurs explicite : retry, dead letter queue, rejeu.

  • La diffusion temps réel vers les interfaces avec Mercure.

  • Un choix de broker argumenté : RabbitMQ, Kafka, ou les deux.

Une décision d'architecture à prendre ?

Parlons-en Retour à l'offre conseil