Naming Convention
About
In ActiveMQ, consistent and descriptive naming conventions are critical for managing message destinations, especially when using features like Virtual Topics, Dead Letter Queues, and multiple consumer groups in a microservices architecture.
Traditional Queue (Producer Side)
What it means: The producer sends a message to a single, named queue.
Message flow: One message goes to one queue.
The broker will deliver the message to one available consumer.
Example
A producer sends order-related messages to the queue named
order-processing.
Traditional Queue (Consumer Side)
Consumers listen to the same queue name:
Each consumer will compete for incoming messages.
Only one consumer will receive any given message.
This is used for load-balanced message processing among multiple instances of the same service.
Example
Service A has three instances (pods) listening to
order-processing.Messages are load-balanced — each pod gets different messages.
Virtual Topic (Publisher-Side Topic)
This is the topic where the producer sends messages.
Each message sent here is duplicated into queues for any subscribed consumers using the matching
queue://Consumer.X.VirtualTopic.<TopicName>format.
Example:
Sent messages are fanned out to:
queue://Consumer.A.VirtualTopic.notificationsqueue://Consumer.B.VirtualTopic.notificationsqueue://Consumer.C.VirtualTopic.notifications... etc.
Each of these queues is isolated. One consumer group does not interfere with others.
Queue Destination (Virtual Topic Consumer Queue)
Components Breakdown:
queue://
Specifies the protocol and that the destination is a queue (not a topic).
Consumer
Prefix to indicate that this queue is a consumer-side queue for a virtual topic.
<ConsumerGroup>
Logical group name of the microservice or consumer. Used to create isolated queues for each group.
VirtualTopic
Fixed keyword required to work with Virtual Topics.
<TopicName>
The name of the virtual topic being subscribed to.
Example:
This means:
Messages were originally published to:
topic://VirtualTopic.notificationsActiveMQ automatically created a copy of the message in a queue:
queue://Consumer.B.VirtualTopic.notificationsThis queue is private to consumer group B, allowing it to process messages independently from other consumers.
Dead Letter Queue (DLQ)
Messages that cannot be processed successfully are sent to the Dead Letter Queue.
Default DLQ for ActiveMQ.
Can be customized using broker configuration.
Helps in debugging failed message deliveries.
Naming in Microservices Context
In microservices, multiple instances (pods) of the same service may consume from the same queue. The naming convention ensures:
Messages are not duplicated between services.
Each service or bounded context receives its own copy of the message (if using Virtual Topics).
Load balancing happens within the group, not across groups.
Example Use Case
Producer:
Consumers:
audit,notification, andanalyticsservices all get the same message, but in their own isolated queues.Each service can independently scale with multiple pods consuming messages from their respective queues.
Best Practices for Naming
Use descriptive consumer group names (e.g., Consumer.NotificationsService)
Helps trace ownership and intent
Keep topic names generic (e.g., VirtualTopic.user.events)
Allows reuse across services
Avoid hardcoding destination names in code
Use environment variables or configuration files
Prefix DLQs with service name (e.g., DLQ.NotificationsService)
Easier to manage failures per service
Use lowercase and hyphens or dots for topic/queue names
Improves readability and consistency
Last updated
Was this helpful?