Event-Driven Consumer
The push consumer, notified in real time — the modern Kafka/SQS/SNS standard.
Problem
Polling introduces latency and consumes resources even when idle. How to be notified without looping?
Forces
- Near-zero latency (< 100 ms).
- No resource waste when the channel is empty.
- Elastic scaling — N parallel consumers pull from the same topic.
- The broker must manage consumer sessions (heartbeat, rebalance) — extra complexity.
Solution
The consumer subscribes to the channel via a callback (Kafka consumer.subscribe, RabbitMQ basic_consume, SQS receive_message with long polling). The broker pushes messages on arrival. Session mechanism (heartbeat) detects dead consumers and rebalances partitions.
EDI implementation
In modern EDI, Event-Driven Consumer is implemented via Kafka Streams (kStream), Spring Cloud Stream, or Camel Kafka component. An edi-parser-orders service subscribes to edi.raw.orders, parses each INVOIC, publishes to edi.parsed.orders. Kubernetes HPA auto-scaling based on consumer lag.
Anti-patterns
- No heartbeat configured — dead consumer not detected, assigned partition blocks indefinitely.
- Too many consumers for available partitions (Kafka) — extras stay idle.
- No offset commit management — infinite replay or message loss.
Related patterns
- Polling Consumer — pull alternative.
- Message Endpoint — parent concept.
- Competing Consumers — associated scaling.
Sources
- Hohpe G., Woolf B. — EIP, Event-Driven Consumer (p. 498). www.enterpriseintegrationpatterns.com/patterns/messaging/EventDrivenConsumer.html