Skip to content
Software Architecture Guide

Polling Consumer

Explanation

Section titled “Explanation”

A Polling Consumer is a receiver that pulls messages from a channel (see Message Channel). It gets nothing until it explicitly asks for a message. The consumer starts each retrieval.

Blocking receive. A polling consumer is also called a synchronous receiver. In a blocking receive, the receiving thread waits until a message arrives. That wait costs a thread. The difference between blocking and non-blocking receive only shows when the consumer polls faster than messages arrive.

Contrast with push. An Event-Driven Consumer is handed messages as they are delivered on the channel. It needs no running thread while idle. A callback thread invokes it when a message arrives. A blocked polling thread, by comparison, sits and waits.

Long polling. Amazon SQS offers two ways to poll. Short polling returns at once, even when no messages are found. Long polling waits, and returns an empty response only if the wait time runs out. It returns messages as soon as they are available. This keeps latency low and avoids repeated empty requests. You turn it on with a wait time above 0, up to 20 seconds. It cuts the cost of empty responses.

Scaling out. Several consumer instances can pull from one queue. This is the Competing Consumers pattern. Each message goes to only one consumer. The consumers pull independently. The queue acts as a buffer and levels the load between producers and consumers.

Acknowledgment. In Azure Service Bus PeekLock mode, a consumer that receives a message hides it from other consumers. The consumer then completes or abandons it.

Example

Section titled “Example”

An order service reads from a queue of new orders. Three copies of the service run. Each copy asks the queue for an order, which hides that order from the other copies. The copy processes the order and then marks it complete. If processing fails, it abandons the order so another copy can try. When the queue is empty, a copy waits for up to a set time before it gets an empty answer.

Trade-offs

Section titled “Trade-offs”
  • Blocking costs a thread. A blocking receive holds a thread while it waits. An Event-Driven Consumer needs no running thread while idle.
  • Empty requests cost money. Short polling returns at once even when nothing is there, so it can produce many empty responses. Long polling reduces them and lowers cost.
  • Wait time has a cap. In SQS, the long polling wait is at most 20 seconds.
  • Competing consumers give each message to one consumer only. This scales throughput. If every consumer must see every message, use Publish-Subscribe instead.

A consumer asks for each message when it is ready.

Diagram source 
sequenceDiagram
  participant C as Consumer
  participant Q as Channel
  C->>Q: Request next message (long poll)
  Note over Q: Waits until a message is available or time expires
  Q-->>C: Message
  C->>C: Process
  C->>Q: Complete
  C->>Q: Request next message

Checks

Section titled “Checks”
  • The document states whether each consumer pulls messages (polling) or is handed them (event-driven).
  • Where consumers block while waiting, the document accounts for the thread each blocked consumer uses.
  • For queue services such as SQS, the document states whether short or long polling is used and the wait time.
  • Where several consumers read one queue, the document states that each message goes to one consumer.
  • The document describes how a pulled message is completed or abandoned.
Section titled “Related”

Sources

Section titled “Sources”