Event-Driven Consumer
Le consumer push, prévenu en temps réel — le standard moderne Kafka/SQS/SNS.
Problème
Le polling introduit une latence et consomme des ressources même à vide. Comment être notifié sans inspecter en boucle ?
Forces
- Latence quasi-zéro (< 100 ms).
- Pas de gaspillage de ressources quand le canal est vide.
- Scaling élastique — N consumers parallèles tirent du même topic.
- Le broker doit gérer les sessions consumer (heartbeat, rebalance) — complexité supplémentaire.
Solution
Le consumer s'abonne au canal via une callback (Kafka consumer.subscribe, RabbitMQ basic_consume, SQS receive_message with long polling). Le broker pousse les messages dès leur arrivée. Mécanisme de session (heartbeat) pour détecter les consumers morts et redistribuer les partitions.
Implémentation EDI
En EDI moderne, l'Event-Driven Consumer est implémenté via Kafka Streams (kStream), Spring Cloud Stream, ou Camel Kafka component. Un service edi-parser-orders s'abonne au topic edi.raw.orders, parse chaque INVOIC, publie sur edi.parsed.orders. Auto-scaling Kubernetes HPA basé sur le consumer lag.
Anti-patterns
- Pas de heartbeat configuré — consumer mort non détecté, partition assignée bloque indéfiniment.
- Trop de consumers pour les partitions disponibles (Kafka) — les surnuméraires sont idle.
- Pas de gestion d'offset commit — replay infini ou perte de messages.
Patterns liés
- Polling Consumer — alternative pull.
- Message Endpoint — concept parent.
- Competing Consumers — scaling associé.
Sources
- Hohpe G., Woolf B. — EIP, Event-Driven Consumer (p. 498). www.enterpriseintegrationpatterns.com/patterns/messaging/EventDrivenConsumer.html