Skip to content
Software Architecture Guide

Event-Driven Consumer

Explanation

Section titled “Explanation”

An Event-Driven Consumer is a receiver that the messaging system calls when a message arrives on its channel. The application does not ask for messages. The consumer passes each message to the application through a callback, which is a function the application supplies.

Delivery triggers the consumer, so no thread runs while it waits. There is no polling loop that keeps checking the channel.

Contrast with a Polling Consumer. A Polling Consumer explicitly asks for a message when it wants one. Its loop is: poll, process, poll again. It sets its own pace. An event-driven consumer does not. Arrivals set its pace.

Burst risk. A burst of messages can overwhelm a single consumer instance. A queue can buffer and level the load, and consumers can autoscale.

Ways to manage load

  • Run several consumers on one channel so they process messages at the same time. This is the Competing Consumers approach.
  • With Kafka, partitions are assigned to consumers in advance. A consumer group cannot have more competing consumers than the topic has partitions.
  • With RabbitMQ, a prefetch limit caps the unacknowledged messages in flight per consumer. This bounds the load on a push consumer. A value of 0 means unlimited, so it gives no protection.

Concurrency in practice. Spring Kafka’s ConcurrentMessageListenerContainer delegates to several single-threaded containers. Together they consume with multiple threads.

Kafka detail. Kafka listener containers still poll internally. They call the listener once per record. The listener model there is a callback on top of a poll loop.

Failures and ordering. Competing consumers give no ordering guarantee, so consumers should be idempotent. That means handling the same message twice causes no harm. Redelivery and poison messages (messages that keep failing) call for dead-letter queues. In Azure Service Bus PeekLock mode, success completes the message. Failure abandons it, so another consumer can retry it.

Example

Section titled “Example”

A shop publishes an order message to a channel. The billing service registered a listener earlier. When the message arrives, the messaging system calls the listener with the order. Billing has no loop and no thread waiting. During a sale, orders flood in. The team adds more billing consumers on the same channel and sets a prefetch limit so each one holds only a few unfinished messages.

Trade-offs

Section titled “Trade-offs”

Delivery-driven consumption is simple, and the consumer needs no polling loop or waiting thread. The cost is control. The consumer does not choose when messages come, so bursts can overload it. You must add limits such as prefetch, more consumers, or buffering queues. More consumers weaken ordering guarantees and require idempotent handling. Kafka caps useful consumers at the partition count.

The broker calls the listener on arrival; a polling consumer asks for each message.

Diagram source 
sequenceDiagram
  participant P as Producer
  participant B as Broker
  participant E as Event-driven consumer
  P->>B: send message
  B->>E: callback with message
  E-->>B: acknowledge

Checks

Section titled “Checks”
  • The document states how a burst of messages is handled, for example through a buffering queue, autoscaling or several competing consumers.
  • Where a push consumer is used with RabbitMQ, a prefetch limit is set and is not 0 (unlimited).
  • Consumers that compete on one channel are idempotent, and failing messages go to a dead-letter queue.
  • For Kafka, the planned consumer count does not exceed the partition count of the topic.
  • The document says whether each consumer is event-driven or polling, and so who controls the consumption pace.
Section titled “Related”

Sources

Section titled “Sources”