# Event-Driven Consumer

> React to messages the instant they arrive — no polling, no lag.

- **Category**: Integration
- **Subcategory**: Messaging Endpoints
- **Canonical URL**: https://designpattern.fyi/patterns/event_driven_consumer/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Fraud detection — payment events trigger a Lambda via SQS event source mapping. Lambda fires within milliseconds of message arrival, runs fraud scoring, and blocks the transaction if suspicious. A polling consumer checking every 30 seconds would be useless here.





## Trade-offs


### Advantages

- Near-zero latency between message arrival and processing start

- Resource-efficient — consumer is idle when no messages are arriving

- Scales naturally with Competing Consumers pattern

- Native support in all modern brokers and serverless platforms




### Considerations & Drawbacks

- Consumer must handle load spikes — sudden bursts can overwhelm it

- Backpressure management is harder than with polling (pull-based consumers control their own rate)

- Error handling for failed messages must be explicit (DLQ, retry logic)

- Can be harder to debug than polling — messages arrive unpredictably







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/EventDrivenConsumer.html)