Point-to-Point vs Publish-Subscribe (Pub/Sub)
Choose the right messaging topology: 1-to-1 worker load distribution vs 1-to-many fan-out broadcast architectures, SNS+SQS fanout patterns, and subscription filtering.
Point-to-Point Queue vs. SNS + SQS Fanout
Publish OrderPlaced events and compare one-consumer work splitting with one-copy-per-domain broadcast.
Events Published
0
1 network call each
Delivered Copies
0
publish to see fan-out
Lost / Buffered
0
safely isolated in own queue
Filter Savings
0
copies the broker skipped
SNS topic → dedicated SQS queue per microservice
📦 Inventory
received: 0
💳 Billing
received: 0
📧 Notification
received: 0
🕵️ Fraud Audit 🔎
received: 0
only amount ≥ $10k
$0.000 per month per 1k events at this fan-out — pub/sub multiplies queue writes by subscriber count (—), which is why attribute filtering matters.
Point-to-point divides work; pub/sub broadcasts facts. With a shared queue, one crashed consumer strand type loses messages for every other domain — the reason Amazon orders emit a single OrderPlacedto SNS and let each team's own SQS queue, DLQ, and scaling policy stay an independent failure domain.
Point-to-Point Work Queue vs Publish-Subscribe Topic Fanout
Comparing 1-to-1 task division with 1-to-many decoupled microservice broadcasting.
01.Point-to-Point Messaging (Queues)
In a Point-to-Point topology, the messaging channel connects one or more producers to a single logical queue. Multiple consumers can pull from the queue, but each message is processed by exactly one consumer:
- Semantic: "Here is a discrete piece of work. Exactly one worker must complete it."
- Lifecycle: Once a consumer pulls and acknowledges the message, the broker deletes it.
- Primary Use Case: Computational job distribution, asynchronous task offloading, and background batch processing (e.g., rendering video chunks or sending individual transactional emails).
02.Publish-Subscribe Topology (Topics & Fan-Out)
In a Publish-Subscribe (Pub/Sub) topology, publishers broadcast messages to a logical channel called a Topic without knowing who (if anyone) is listening. Multiple independent subscribers bind to the topic, and the messaging infrastructure delivers an isolated copy of the message to every subscriber:
- Semantic: "A significant business event occurred (
OrderPlaced). Anyone interested should act on it." - Zero-Coupling Extensibility: When the engineering team creates a new
RecommendationEngineorComplianceAuditservice, they simply subscribe to the existing topic. The publishing service requires zero code modifications, zero redeployments, and zero downtime. - Subscription Filtering: Modern Pub/Sub brokers (Amazon SNS, Google Cloud Pub/Sub, Azure Service Bus) support attribute-based filtering. A subscriber can configure a filter policy such as
{"region": ["EU"], "amount": [{"numeric": [">=", 10000]}]}, receiving only high-value European transactions while the broker discards irrelevant events before delivery.
03.The Industry Standard: SNS + SQS Fanout Architecture
Directly pushing messages from a Pub/Sub topic to HTTP endpoints or Lambda functions creates dangerous coupling: if the subscriber's endpoint experiences an outage, messages can be dropped or require complex broker retry storms.
The industry-standard solution is the Topic-to-Queue Fanout Pattern (e.g., AWS SNS fanning out to dedicated Amazon SQS queues):
- Single Publish Hop: The upstream service issues a single fast HTTP call to publish an event to the SNS topic (
sim 10ms). - Atomic Fanout: SNS replicates the event and places an identical copy into the private SQS queue of every subscribing microservice.
- Independent Failure Domains & Speed:
- The Inventory service can process messages at
5,000 msgs/sec. - The Billing service can process at
1,000 msgs/sec. - If the Notification service crashes for two hours, its dedicated SQS queue buffers messages safely without affecting Inventory or Billing.
- Each subscriber has its own isolated Dead-Letter Queue (DLQ) and retry policy.
- The Inventory service can process messages at
04.Architectural Comparison & Selection Matrix
| Dimension | Point-to-Point (Queue) | Publish-Subscribe (Topic Fanout) |
|---|---|---|
| Cardinality | 1 Producer → 1 Consumer per message | 1 Publisher → N Independent Subscribers |
| Consumer Knowledge | Workers pull identical task types from a shared pool | Subscribers have distinct business domains |
| Extensibility | Adding workers increases throughput of the same task | Adding subscribers introduces entirely new application features |
| Coupling | Producer coupled to task contract | Zero coupling between publisher and consumers |
| Message Duplication | No (single message consumed once) | Yes (broker duplicates message for each active subscription) |
| Primary Technologies | AWS SQS, RabbitMQ Queues, Celery, Sidekiq | AWS SNS + SQS, Google Cloud Pub/Sub, RabbitMQ Fanout Exchange, Kafka |
Architectural Trade-offs & Production Realities
Architectural Advantages
- Pub/Sub enables true architectural decoupling: add new downstream consumers without altering upstream systems
- Fanout queues provide isolated failure domains: an outage in one subscriber never impacts other consumers
- Point-to-point queues maximize worker resource utilization through automatic load leveling
Trade-offs & Constraints
- Pub/Sub multiplies overall network egress and queue storage costs proportional to subscriber count
- Eventual consistency and race conditions between multiple independent subscribers require careful coordination
When a customer purchases an item on Amazon, the Order Processing service emits a single OrderPlaced event to an internal SNS topic. This topic instantly fans out copies into separate SQS queues for Credit Card Settlement, Fulfillment Centers, Merchant Seller Portals, Recommendation ML Pipelines, and Customer Email Notifications. Each downstream team maintains their own queue configurations and worker scaling policies independently.
Staff+ Engineering Takeaways
- Point-to-point queues deliver each message to a single competing worker.
- Pub/Sub topics broadcast copies of each event to all subscribed queues or services.
- The SNS + SQS Fanout pattern combines broadcast flexibility with queue isolation and fault buffering.
- Subscription filter policies allow subscribers to ingest only the subset of events they care about.
Topic Knowledge Check
Exercise 1 of 3 • Test your architectural comprehension.
In an e-commerce platform, when an order is placed, both the Fraud Detection service and the Shipping service must receive the transaction details. Which architecture is optimal?
How clear and actionable was this distributed systems breakdown?