This content originally appeared on DEV Community and was authored by Arnav Sharma
What is Pub/Sub?
Publish/Subscribe (pub/sub) is a messaging pattern where publishers send messages without knowing who will consume them, and subscribers receive messages without knowing who produced them.
A broker (like Kafka, RabbitMQ, SQS, Redis) usually sits in the middle to handle message delivery.
This decoupling allows systems to communicate asynchronously and scale independently.
Why Pub/Sub?
Pub/Sub solves several common problems in distributed systems:
Decoupling – Publishers don’t need to know subscribers.
Scalability – Multiple subscribers can process messages independently.
Reliability – Messages are queued until consumed (depending on broker).
Flexibility – One message can be delivered to many subscribers (fanout).
When Pub/Sub?
Use pub/sub when:
You want event-driven architecture (e.g., user signup triggers emails, notifications).
You need to scale workers dynamically.
You need loose coupling between microservices.
You need to ensure asynchronous processing (background jobs, pipelines).
Don’t use pub/sub when you need strict request/response (synchronous API calls).
How Pub/Sub (Types)
There are two main ways subscribers receive messages:
Push-based Pub/Sub
The broker pushes messages directly to subscribers.
Subscribers don’t need to poll.
Example: RabbitMQ pushes messages to consumers.
Low latency
Easy subscriber logic
Risk of overwhelming slow subscribers
Pull-based Pub/Sub
Subscribers request (pull) messages from the broker when ready.
Example: AWS SQS requires consumers to poll for messages.
Subscribers control pace (backpressure handling)
Reliable retries
Slightly higher latency due to polling
Comparison
| Feature | Push-based Pub/Sub | Pull-based Pub/Sub |
|---|---|---|
| Delivery model | Broker delivers | Subscriber requests |
| Latency | Lower (instant delivery) | Higher (polling delay) |
| Backpressure control | Harder | Easier |
| Subscriber logic | Simple (just receive) | More complex (polling) |
| Example tech | RabbitMQ, Redis Pub/Sub | AWS SQS, Kafka |
Which Tech Uses Which One and How?
RabbitMQ (Push-based)
Consumers register with a queue.
RabbitMQ pushes messages to consumers.
You can configure prefetch to avoid overloading consumers.
Great for real-time apps (chat, IoT, financial trading).
AWS SQS (Pull-based)
Messages are stored in SQS queues.
Consumers must poll SQS to fetch them.
Can use long polling for efficiency.
Great for cloud pipelines, serverless apps, microservices decoupling.
Real World Example
Imagine an e-commerce platform:
A customer places an order.
Publisher: Order service emits an
order_createdevent.Push-based: A notification service instantly gets the event via RabbitMQ and sends an SMS.
Pull-based: A reporting service pulls events from SQS at its own pace to update sales dashboards.
Conclusion
Both pull-based and push-based pub/sub models have their strengths:
Push-based is best when you need low latency, real-time delivery (RabbitMQ, Redis Pub/Sub).
Pull-based is best when you need scalability, reliability, and backpressure control (AWS SQS, Kafka).
The right choice depends on your use case:
For real-time notifications, go with push.
For background processing or analytics, go with pull.
In modern architectures, teams often combine both models—push for immediate actions, pull for batch or heavy workloads.
This content originally appeared on DEV Community and was authored by Arnav Sharma