top of page
Search

Point-to-Point vs. Publish-Subscribe

  • Writer: NNW Tech Solutions
    NNW Tech Solutions
  • Aug 12
  • 6 min read

Updated: Aug 13

The Queue and Pub/Sub Litmus Test



ree

You've likely worked with systems where components need to communicate. But have you ever felt that nagging uncertainty about the difference between a queue and a publish-subscribe (Pub/Sub) model? While both are powerful asynchronous tools, they're built for fundamentally different jobs. We're writing this article because, as it turns out, that very distinction is a hallmark of a senior developer's insight. It's not just about knowing what the tools are, but understanding why they exist.


Think of a queue as a single 'inbox' where only one person can read a message before it's deleted. The Pub/Sub model is like a 'broadcast channel' where everyone with a radio tuned to that station gets the same message at the same time. We're going to dive into the core principles behind these two communication patterns and give you the clarity you need to build more scalable, resilient systems.





What is a Message Queue?


At its heart, a message queue is a way to handle a stream of tasks in a point-to-point fashion. A producer sends a message (a task) to the queue, and then a consumer picks up that message and works on it. Crucially, only one consumer can process a single message from the queue. Once a message is successfully consumed, it's removed. The message broker holds onto the message until a consumer confirms it has been processed, which is why it offers a high degree of confidence in guaranteed delivery. This confirmation is known as an acknowledgement, and if the consumer fails before sending it, the message remains visible or is redelivered.



Pros

Guaranteed Delivery: A message is never lost as it waits in the queue until a consumer successfully processes it.


Ordered Processing: Queues can be configured to process messages in the order they were received (FIFO - First-In, First-Out), which is vital for many workflows.


Load Balancing: You can have multiple consumers listening to the same queue, and the queue will distribute the messages among them, helping to scale your processing.

Cons

No Broadcasting: Not designed for one-to-many communication. You can't have multiple independent services react to the same message easily.


Potential Bottleneck: A backup of one type of message can block others if not managed correctly. This is often called head-of-line blocking.


Complexity: You must design your consumer logic to be idempotent, meaning it can safely process the same message multiple times without causing side effects, as messages can be redelivered.




Where to Use It: The Payment Example


A message queue is the ideal choice for any mission-critical task that must be done exactly once. The most classic example is a payment processing system.


When a user clicks "Pay," your front-end service adds a process_payment message to a queue. Because a queue guarantees that only one worker will handle this message, you don't have to worry about accidentally charging the customer twice. The message sits in the queue, waiting for a payment processor service to come online and confirm the transaction.





What is the Publish-Subscribe (Pub/Sub) Pattern?


In contrast, the publish-subscribe pattern is a messaging paradigm designed for one-to-many communication. Instead of sending a message to a single, specific receiver, a publisher sends a message to a topic (or channel). All subscribers who are interested in that topic receive a copy of the message.


The beauty of Pub/Sub lies in its strong decoupling. Publishers don't need to know who the subscribers are or how many there are. Similarly, subscribers don't need to know who published the message. This makes it perfect for event-driven architectures.



Pros

Strong Decoupling: Publishers and subscribers are completely unaware of each other, making the system highly flexible and easy to extend.


Massive Scalability: Adding a new service that needs to react to an event is as simple as adding a new subscriber. No changes are required to the publisher.

Cons

No Guaranteed Delivery (by default): This is the core difference. Pub/Sub is about broadcasting, not holding. The broker delivers the message, but if a subscriber is offline, the message might be lost. (Note: Many modern brokers offer "durable subscriptions" to mitigate this, but it’s an architectural decision).


Complex Failure Handling: It can be difficult to track and confirm if every single subscriber successfully processed a message. Debugging distributed systems can be challenging.




Where to Use It: The Payment Example, Revisited


While a queue is perfect for the payment transaction itself, Pub/Sub is the best choice for all the downstream effects of that payment.


Once the payment is successful, the payment service could publish a payment_successful message to a payments topic. This one message can then trigger multiple independent actions:


  • The Email Service receives the message and sends a receipt.

  • The Inventory Service receives the message and updates stock levels.

  • The Fraud Detection Service receives the message and performs a final check.

  • The Logging Service receives the message and archives the event.


Each of these services can operate completely independently without needing to know about each other.





A Practical Look: Code Snippets & Offline Consumers


Understanding the code helps clarify the intent of each pattern.


Queue Example (Point-to-Point)


Here's how a producer and consumer might interact with a queue. The consumer is designed to process the message and then acknowledge it, ensuring it won't be processed by another consumer.


// Producer
queue.send('process_payment', { id: 123, amount: 100 });

// Consumer
function processPayment(message) {
  try {
    // Logic to handle the payment...
    queue.ack(message); // Acknowledge message is processed
  } catch (error) {
    queue.requeue(message); // On failure, put message back in queue
  }
}



Pub/Sub Example (One-to-Many)


The Pub/Sub pattern is all about publishing an event without caring who receives it.


// Publisher
topic.publish('payment_successful', { id: 123, amount: 100 });

// Subscriber A (e.g., Email Service)
topic.on('payment_successful', (message) => {
  // Logic to send a receipt email...
});

// Subscriber B (e.g., Inventory Service)
topic.on('payment_successful', (message) => {
  // Logic to update inventory levels...
});



What Happens When a Consumer is Offline?


This is a critical question that exposes the fundamental difference in how these two patterns handle resiliency.


  • With a Queue: If a consumer goes offline, the messages simply pile up in the queue. They are safely stored by the broker and will be processed as soon as a consumer becomes available again. The system is resilient to consumer failure.

    • For unprocessable messages that fail repeatedly, most brokers use a Dead-Letter Queue (DLQ), which is a special queue where these "poison pill" messages are sent.


  • With a Pub/Sub: This is more nuanced. In a simple Pub/Sub model, if a subscriber is offline when a message is published, that message is lost to that subscriber. The broker has no knowledge of the subscriber's state or the need to redeliver. However, modern implementations with features like durable subscriptions (e.g., in AWS SNS/SQS) or a distributed log (e.g., Kafka) will store the messages for a period of time, allowing a subscriber to catch up once they come back online. This is a crucial architectural choice.





The Senior Developer's Litmus Test


Why does this distinction truly matter? Because many so-called senior developers don't know it. A junior developer might reach for a simple message queue to solve every asynchronous problem. A senior developer, on the other hand, understands that choosing the right pattern is a critical architectural decision.


  • System Design: A deep grasp of queues and Pub/Sub is essential for designing scalable and resilient systems. It allows you to make informed decisions about whether a task should be processed uniquely or broadcast as a notification.

  • Problem-Solving: When things go wrong in a complex system, understanding these concepts allows for more effective debugging. You'll know to check the queue's dead-letter policies for a failed one-to-one task, or to look at a topic's subscribers to ensure an event was properly broadcast.

  • Interview Insight: This is a litmus test. A clear, articulate explanation of the differences between queues and Pub/Sub in an interview demonstrates your ability to think architecturally and your experience with real-world system design. It shows true mastery beyond just coding.


In conclusion, both message queues and the Pub/Sub pattern are powerful tools in a developer's arsenal. While both are asynchronous, they are not interchangeable. A queue makes your systems reliable for point-to-point tasks, while Pub/Sub makes them flexible for one-to-many event broadcasting. Understanding their distinct roles is a non-negotiable skill for anyone aiming to build high-performance, scalable applications.



What are some interesting ways you've used queues or Pub/Sub in your projects? Share your thoughts and experiences.

 






Looking for the Right Talent? NNW Can Help.


We specialise in connecting companies with the best tech professionals

— people who don’t just fill roles but drive innovation.


Let’s talk about your hiring needs! 




 
 
 
bottom of page