Event-Driven Consumer

An Event-Driven Consumer is a message endpoint that the messaging system calls automatically when a message becomes available. Instead of the application asking for messages, it registers a callback or handler, and the broker pushes each message to it. This inverts control: the consumer is invoked, it does not invoke.

The problem it solves is timely, low-overhead reaction. When a consumer should respond as soon as a message arrives and should not waste cycles polling, an event-driven model delivers messages on demand and lets the consumer stay idle until there is work.

How It Works

The consumer registers a handler with the messaging infrastructure — a JMS MessageListener, a Kafka consumer with a listener container, an AWS Lambda triggered by a queue or stream, or a webhook endpoint. When a message arrives, the infrastructure invokes the handler with the message. After successful processing the consumer acknowledges, and the broker removes or advances past the message.

The messaging provider manages threading, prefetch, and delivery, so the consumer focuses on processing logic. Concurrency is typically configured (number of listener threads or instances) rather than coded by hand.

broker --(message arrives)--> invokes handler(message) --> process --> ack

When to Use It

Use it when low latency matters, when you want the broker to manage delivery and concurrency, or when building reactive, serverless, or event-driven systems. It suits most real-time messaging where push delivery is available and is the default in frameworks like Spring and serverless platforms.

Avoid it when the consumer must strictly control its own consumption rate or process in scheduled batches; a polling consumer is better there. Pushed delivery can overwhelm a slow consumer unless backpressure or prefetch limits are configured.

Trade-offs

Event-driven consumption is efficient and low-latency, with the broker handling delivery mechanics. The trade-off is reduced control: the consumer reacts to the broker's pace, so it needs prefetch limits, concurrency tuning, and backpressure to avoid overload. Error handling on a pushed message must decide between acknowledge, retry, and dead-letter.

Related Patterns

It is the counterpart of the Polling Consumer. Competing Consumers scale event-driven processing across instances. A Message Dispatcher routes pushed messages to specific handlers. All are Message Endpoints.

Example

An AWS Lambda function is configured with an SQS event source. When messages arrive, Lambda invokes the function with a batch, scaling instances automatically with load. The developer writes only the handler; AWS manages polling, invocation, and concurrency behind the event-driven facade.