Queue vs Topic

Learn the differences between Queue and Topic messaging models with Spring Boot, Apache Kafka, RabbitMQ, Amazon SQS, Amazon SNS, JMS, and enterprise messaging architectures. Understand Point-to-Point vs Publish-Subscribe communication with real-world examples and architecture diagrams.

Introduction

Modern enterprise applications communicate continuously.

Examples:

Banking Systems
Insurance Platforms
Healthcare Applications
E-Commerce Website
Logistics Platforms
Financial Trading Systems
IoT Platforms
Social Media

Instead of calling each other directly,

applications exchange messages.

Messaging enables:

Loose Coupling
Scalability
Reliability
Fault Tolerance
Asynchronous Processing

The two most common messaging models are:

Queue
Topic

Although both transport messages between applications, they solve different business problems.

Understanding when to use each model is essential for designing scalable enterprise systems.

Why Messaging?

Imagine a customer places an order.

Business actions required:

Process Payment
Update Inventory
Send Email
Generate Invoice
Notify Warehouse
Update Analytics

Should every service receive the same message?

Or should only one service process it?

The answer depends on whether we use a Queue or a Topic.

What is a Queue?

A Queue follows the Point-to-Point messaging model.

Characteristics:

One Producer
One Queue
One Consumer processes each message
Messages are removed after successful processing

A message is intended to be processed only once.

Queue Architecture

flowchart LR

Producer

-->

Queue

Queue --> Consumer

One message

↓

One consumer

Queue Workflow

sequenceDiagram

participant Producer

participant Queue

participant Consumer

Producer->>Queue: Send Message

Queue->>Consumer: Deliver Message

Consumer-->>Queue: ACK

After acknowledgment,

the message is removed from the queue.

Queue Example

Customer places an order.


Order

↓

Queue

↓

Order Processing Service

Only one service processes the order.

Queue Characteristics

Point-to-Point
Single Processing
Work Distribution
Load Balancing
High Throughput
Background Processing

Ideal for task execution.

What is a Topic?

A Topic follows the Publish-Subscribe (Pub/Sub) model.

Characteristics:

One Producer
One Topic
Multiple Subscribers
Every subscriber receives a copy of the message

The producer does not know who receives the event.

Topic Architecture

flowchart LR
    PRODUCER["Producer"]

    TOPIC["Kafka Topic"]

    EMAIL["Email Service"]
    INVENTORY["Inventory Service"]
    ANALYTICS["Analytics Service"]
    NOTIF["Notification Service"]

    PRODUCER --> TOPIC

    TOPIC --> EMAIL
    TOPIC --> INVENTORY
    TOPIC --> ANALYTICS
    TOPIC --> NOTIF

One event

↓

Many consumers

Topic Workflow

sequenceDiagram

participant Producer

participant Topic

participant Email

participant Inventory

participant Analytics

Producer->>Topic: Publish Event

Topic->>Email: Copy

Topic->>Inventory: Copy

Topic->>Analytics: Copy

Every subscriber processes the event independently.

Queue vs Topic

The biggest difference is how messages are consumed.

Queue:


One Message

↓

One Consumer

Topic:


One Message

↓

Many Consumers

High-Level Comparison

flowchart LR

Producer

-->

Queue

Queue --> Consumer

Producer

-->

Topic

Topic --> ConsumerA

Topic --> ConsumerB

Topic --> ConsumerC

Queue Processing

Suppose:

100 Orders


100 Orders

↓

Queue

↓

Worker 1

Worker 2

Worker 3

Workers divide the workload.

Each order is processed exactly once (assuming successful processing).

Topic Processing

Suppose:

Order Created Event


Order Created

↓

Topic

↓

Email

Inventory

Billing

Analytics

Every service receives the event.

Queue Use Cases

Queues are ideal when work must be processed only once.

Examples:

Order Processing
Payment Processing
Invoice Generation
Image Processing
Background Jobs
Batch Processing

Topic Use Cases

Topics are ideal when multiple services react to the same event.

Examples:

Order Created
Customer Registered
Payment Completed
Claim Approved
Shipment Delivered

Queue in Banking

Money transfer request.


Transfer Request

↓

Queue

↓

Transaction Processor

Only one processor should execute the transaction.

Topic in Banking

Payment completed.


Payment Completed

↓

Topic

↓

Fraud Detection

↓

Notifications

↓

Analytics

↓

Audit

Every service receives the event.

Queue in Insurance

Claim processing.


Claim

↓

Queue

↓

Claim Processor

Only one processor handles the claim.

Topic in Insurance

Claim approved.


Claim Approved

↓

Topic

↓

Billing

↓

Customer Notification

↓

Analytics

Queue in Healthcare

Laboratory request.


Lab Request

↓

Queue

↓

Lab System

The request is processed once.

Topic in Healthcare

Patient admitted.


Patient Admitted

↓

Topic

↓

Billing

↓

Room Allocation

↓

Pharmacy

↓

Notification

Every department receives the event.

Queue in Retail

Order fulfillment.


Order

↓

Queue

↓

Warehouse Worker

One worker processes each order.

Topic in Retail

Product added.


New Product

↓

Topic

↓

Search

↓

Recommendation

↓

Analytics

↓

Cache Refresh

All interested services react.

Queue Scaling

Queues support competing consumers.

flowchart LR
    Q["Queue"]

    A["Worker A"]
    B["Worker B"]
    C["Worker C"]

    Q --> A
    Q --> B
    Q --> C

Messages are distributed among workers.

This improves throughput.

Topic Scaling

Topics support independent consumers.

flowchart LR
    TOPIC["Topic"]

    CGA["Consumer Group A"]
    CGB["Consumer Group B"]
    CGC["Consumer Group C"]

    TOPIC --> CGA
    TOPIC --> CGB
    TOPIC --> CGC

Each group processes its own copy of the event.

Message Lifecycle

Queue


Send

↓

Store

↓

Process

↓

Delete

Topic


Publish

↓

Distribute

↓

Multiple Consumers

↓

Independent Processing

Message Ordering

Queue:

Ordering may depend on broker implementation.

Examples:

FIFO Queues
Standard Queues

Topic:

Ordering is typically maintained within a partition or subscription, depending on the messaging system.

Delivery Guarantees

Queue:

Typically:

At Least Once
At Most Once
FIFO (depending on technology)

Topic:

Depends on broker capabilities.

Consumers process events independently.

Spring Boot Integration

Spring Boot supports:

Queues:

RabbitMQ
Amazon SQS
JMS

Topics:

Apache Kafka
Amazon SNS
JMS Topics

Spring provides dedicated integrations for each messaging platform.

RabbitMQ

RabbitMQ primarily focuses on queues.

Features:

Reliable Delivery
Routing
Exchanges
Work Queues

Suitable for task processing.

Apache Kafka

Kafka is an event streaming platform built around topics.

Features:

Publish-Subscribe
High Throughput
Event Streaming
Replay
Partitioning

Ideal for event-driven architectures.

Amazon SQS

Amazon SQS provides managed queues.

Supports:

Standard Queue
FIFO Queue
Dead Letter Queue

Suitable for asynchronous background processing.

Amazon SNS

Amazon SNS provides publish-subscribe messaging.

One message can reach:

Email
SMS
Lambda
SQS
HTTP Endpoints

Ideal for event broadcasting.

Enterprise Architecture

flowchart TD

CLIENT[Client]

CLIENT --> ORDER[Order Service]

ORDER --> QUEUE[(Order Queue)]

QUEUE --> PROCESSOR[Order Processor]

ORDER --> TOPIC[(Order Events)]

TOPIC --> INVENTORY[Inventory Service]

TOPIC --> BILLING[Billing Service]

TOPIC --> ANALYTICS[Analytics Service]

TOPIC --> NOTIFICATION[Notification Service]

One application commonly uses both queues and topics together.

Queue vs Topic Comparison

Feature	Queue	Topic
Communication Model	Point-to-Point	Publish-Subscribe
Consumers	One	Many
Message Processing	Once	Multiple Times
Work Distribution	Yes	No
Event Distribution	No	Yes
Background Jobs	Excellent	Moderate
Event-Driven Systems	Limited	Excellent
Typical Technologies	RabbitMQ, SQS	Kafka, SNS

When to Use Queue

Use Queue when:

One consumer should process a task.
Work needs load balancing.
Background jobs are required.
Task processing must occur exactly once (or at least once with idempotency).

Examples:

Payment Processing
Report Generation
Invoice Creation
Image Processing

When to Use Topic

Use Topic when:

Multiple services react to one event.
Event-driven architecture is required.
Services should remain loosely coupled.
Business events must be distributed.

Examples:

Order Created
Payment Completed
Customer Registered
Shipment Delivered

Best Practices

Use queues for work distribution.
Use topics for business events.
Make consumers idempotent.
Configure retries and Dead Letter Queues.
Monitor consumer lag.
Keep messages small and immutable.
Avoid embedding business logic in brokers.
Version message schemas.
Preserve ordering only where required.
Secure messaging infrastructure.

Common Mistakes

❌ Using queues for event broadcasting.

❌ Using topics for single-worker jobs.

❌ Ignoring duplicate message handling.

❌ No Dead Letter Queue.

❌ Large message payloads.

❌ Tight coupling between producers and consumers.

Interview Questions

What is a Queue?
What is a Topic?
Explain Point-to-Point messaging.
Explain Publish-Subscribe messaging.
When should you use a Queue?
When should you use a Topic?
What is the difference between RabbitMQ and Kafka?
How do Amazon SQS and Amazon SNS differ?
Why are topics useful in Event-Driven Architecture?
Can an enterprise application use both queues and topics?

Summary

Queues and Topics are the two fundamental messaging models used in distributed systems.

A Queue delivers each message to a single consumer, making it ideal for task processing, background jobs, and workload distribution.

A Topic distributes a copy of each event to multiple subscribers, making it ideal for event-driven architectures, notifications, analytics, and business event propagation.

A production-ready enterprise architecture often combines both:

Queues for reliable task execution.
Topics for event broadcasting.

Technologies such as RabbitMQ, Amazon SQS, Apache Kafka, and Amazon SNS implement these messaging patterns and power large-scale applications across banking, insurance, healthcare, retail, logistics, and cloud-native platforms.