Skip to main content

Event Brokers: Push vs Pull

Push and pull are two different delivery models for events. Each model changes reliability, latency, and how you handle overload.

Simple Explanation​

What it is​

Push means the broker sends events to your function immediately. Pull means your worker asks the broker for messages when it is ready.

Why we need it​

The delivery model determines how your system behaves under load. Pick the wrong one and you either drop data or overwhelm your services.

Benefits​

  • Clearer capacity planning when you choose the right model.
  • Fewer failures because overload is handled correctly.

Tradeoffs​

  • Push can overwhelm consumers if you cannot scale fast enough.
  • Pull can add latency if polling is slow or batch sizes are too large.

Real-world examples (architecture only)​

  • Push: Pub/Sub -> Function for real-time processing.
  • Pull: Queue -> Worker for batch processing.

Push delivery model Pull delivery model

Core Concepts​

  • Push delivery: Broker calls your endpoint or triggers your function.
  • Pull delivery: Worker polls the broker and acknowledges work.
  • Backpressure: How you slow down producers when consumers are overloaded.
  • Ack semantics: What happens when a message is not acknowledged.
  • Batching: Pull allows controlled batch sizes to improve throughput.

Push Model (When the Broker Sends Events)​

Typical services: SNS -> Lambda, Pub/Sub push -> Cloud Run/Functions.

Good for:

  • Real-time alerts and notifications
  • Low-latency processing
  • Fan-out (one event -> many consumers)

Risks:

  • Sudden bursts can overwhelm consumers
  • Retries can amplify load if errors happen

Python example (GCP Pub/Sub push)

import base64
import json


def pubsub_push(request):
	envelope = request.get_json(silent=True) or {}
	message = envelope.get("message", {})
	data = base64.b64decode(message.get("data", "")).decode("utf-8")
	event = json.loads(data or "{}")

	process_event(event)
	return ("OK", 200)

Pull Model (When Workers Fetch Events)​

Typical services: SQS, Pub/Sub pull, Cloud Tasks pull.

Good for:

  • Controlled throughput
  • Batch processing
  • Heavy workloads that need steady pacing

Risks:

  • Increased latency (polling interval)
  • More worker management

Python example (SQS worker)

import json
import boto3

sqs = boto3.client("sqs")
QUEUE_URL = "https://sqs.REGION.amazonaws.com/ACCOUNT/queue"


def poll_and_process():
	response = sqs.receive_message(
		QueueUrl=QUEUE_URL,
		MaxNumberOfMessages=10,
		WaitTimeSeconds=10,
	)

	for record in response.get("Messages", []):
		body = json.loads(record["Body"])
		process_event(body)
		sqs.delete_message(QueueUrl=QUEUE_URL, ReceiptHandle=record["ReceiptHandle"])

Decision Matrix​

RequirementPrefer PushPrefer Pull
Low latency✅❌
Controlled throughput❌✅
Simple consumer✅❌
Heavy batch work❌✅
Fan-out to many services✅❌

Backpressure Strategies​

  • Push: throttle at the broker, add queues between services, use DLQs.
  • Pull: adjust batch size and visibility timeout, scale workers gradually.

Project​

Design two versions of the same workflow:

  1. Push model for low-latency events.
  2. Pull model for heavy batch processing.

Deliverables:

  • Describe the architecture for both models.
  • Explain which model you would choose and why.
  • List failure scenarios and how each model handles them.

Email your work to maarifaarchitect@gmail.com.

References​