Understanding push vs poll in event-driven architectures

When we talk about event-driven architectures, we often focus on things like loose coupling, scalability and DDD. But under the hood, the way consumers receive events matters just as much. And it usually comes down to one of two models: push vs poll. Your choice dictates what service(s) you use and how you handle errors.

So let’s compare the two models and understand their pros & cons.

Push: best for pub/sub

In a push model, events are delivered to consumers as soon as they happen. Think SNS -> Lambda or webhooks. The event producer (or broker) is responsible for delivering the event to one or more subscribers.

Push works great for pub/sub use cases, where the goal is to fan out an event to many downstream systems in real-time.

Pros

• Low end-to-end latency: consumers receive the event as soon as it happens.
• No polling overhead: no wasted compute cycles when there are no events.
• Great for notifications, fan-out, or triggering workflows.

Cons

• Harder to control throughput: if 100 events come in, you’ll get 100 invocations, ready or not.
• Harder to manage backpressure.
• If the consumer is down, the broker must handle retries and support dead-letter queues (DLQ) to avoid data loss. Consumers also need to decide how to reprocess messages from the DLQ.

SNS + Lambda is a great example of the push model. But as I explain in this article [1], it isn’t a pure push!

SNS pushes to Lambda, but behind the scenes, Lambda queues the event and polls it from an internal queue before processing. So it feels like push, but there’s polling under the hood.

Poll: best for stream processing

In a poll model, consumers pull events on their own schedule. Think Kinesis, DynamoDB Streams, or Kafka. The consumer is responsible for checking for new messages and deciding when and how much to process.

Polling is ideal for stream processing, where you often care about ordering, batch processing and checkpointing.

Pros

• Full control over throughput and concurrency.
• Consumers can checkpoint and retry failed records independently.
• Easier to build robust, fault-tolerant processing logic.

Cons

• Higher latency, especially if polling intervals are large.
• More infrastructure to manage (shards, offsets, consumer groups, etc.)

This is why stream processing tools like Kinesis, Kafka and DynamoDB Streams are all poll-based. These services are designed to ingest and process large amounts of data, and they want to give you (the consumer) more control. You can choose batch size, polling frequency and how you handle errors and retries.

Interestingly, Lambda event-source mapping converts the poll model into a push! It’s an often under-appreciated aspect of Lambda and significantly simplifies stream processing. Check out this post [2] if you want to learn more about how it works.

When to use push vs poll?

Use push when:

• You want to react to events as soon as possible.
• You’re doing pub/sub and don’t care about ordering.
• The processing is lightweight and can scale with the incoming event rate.

Use poll when:

• You need strict control over how events are processed.
• You want batching, customizable retry behaviour, and checkpoints.
• You’re working with ordered event streams.

In practice, you’ll often use both. Push for notifications and workflows. Poll for stream processing and high-throughput workloads.

Also, understanding the nature of the event helps. Is it a command or an event? That distinction influences not just who should consume it, but how. I went deeper into that topic here [3].

Final thoughts

Push and poll are tools. And like other tools, they’re best suited for different contexts. Just because a service supports one model doesn’t mean you must architect your system around it.

Lambda’s async invocations (with the internal queue) and event-source mappings are good examples of how to convert push into poll and vice versa.

Links

[1] Here is one of the most misunderstood aspects of AWS Lambda

[2] Understand how Lambda Event-Source Mapping works

[3] Event-Driven Architecture: know your commands from events

Related Posts