Polling Consumer
A Polling Consumer actively checks the channel for messages on its own schedule, giving the application control over consumption rate and batching. Long polling and batch fetches reduce the latency and waste inherent in naive polling.
A Polling Consumer is a message endpoint that actively asks the channel whether a message is available, retrieving one (or a batch) when it is. The application controls the timing: it decides when to poll and therefore how fast it consumes. It is sometimes called a synchronous receiver because the receive call blocks or returns immediately based on availability.
The problem it solves is consumption control. Some consumers must regulate their own throughput — to avoid overload, to process in batches, or to fit a scheduled window. Polling gives the consumer the initiative rather than letting the broker push at an uncontrolled rate.
How It Works
The consumer runs a loop. On each iteration it calls receive on the channel. If a message is present it processes it and acknowledges; if not, the call returns empty (or blocks up to a timeout) and the consumer waits before polling again. Long polling reduces wasted calls by letting the broker hold the request open until a message arrives or a timeout expires.
Batch polling fetches several messages per call to amortize round-trips. The polling interval and batch size are the main tuning knobs, trading latency against efficiency.
loop { msg = channel.receive(timeout); if msg: process(msg) else: wait }
When to Use It
Use it when the consumer must control its consumption rate, when processing is batch-oriented or scheduled, when the messaging system offers no push delivery, or when integrating with resources that cannot tolerate bursts. AWS SQS, which has no native push to arbitrary consumers, is fundamentally polled.
Avoid it when low-latency reaction matters and the broker supports push; constant polling wastes resources and adds latency.
Trade-offs
Polling gives precise rate control and simple flow management but can waste resources polling an empty channel and adds latency equal to the polling interval. Long polling mitigates both. The consumer owns the loop, threading, and error handling, which is more code than an event-driven consumer requires.
Related Patterns
It is the counterpart of the Event-Driven Consumer, which is pushed to. Competing Consumers can each poll the same queue. A Message Dispatcher may distribute polled messages to handler threads. Both are kinds of Message Endpoint.
Example
A worker reads from an SQS queue with ReceiveMessage using long polling (wait time 20 seconds) and a batch size of 10. It processes the batch, deletes the handled messages, and loops, throttling itself so a downstream database is never overwhelmed.