Messaging Fundamentals

Message-oriented middleware is infrastructure, usually a message broker, that sits between applications and transfers messages from producers to consumers. A producer sends a message to a named destination; the broker stores it reliably and delivers it to one or more consumers, possibly much later. Because the broker holds the message, the producer and consumer never need to be running at the same time, and neither needs to know the other's location. Examples include ActiveMQ Artemis, IBM MQ and RabbitMQ, typically used through Jakarta Messaging. This decoupling in time and location is the main reason for using messaging.

A queue implements point-to-point messaging: each message is delivered to exactly one consumer, even if several consumers are listening, so queues are used for work that must be done once, such as processing a payment. A topic implements publish-subscribe: each message is delivered to every current subscriber, so topics are used to broadcast facts that several systems care about, such as an order having been placed. Choosing between them is a design decision about who should act on a message. Many brokers also offer shared subscriptions, which combine a topic with several competing consumers per subscriber.

Competing consumers are several consumer instances reading from the same queue. The broker gives each message to only one of them, so they share the workload and throughput scales by adding consumers; if one fails, the others continue. For example, five instances of an invoice service can process invoice requests in parallel. The trade-off is ordering: messages are processed concurrently by different consumers, so a later message can finish before an earlier one. If order matters for related messages, such as updates to the same account, use message groups or partitioning so each group is handled by one consumer at a time.

Use a command when the sender needs a specific action to be performed by a specific recipient, for example ChargeCard or SendInvoice. Commands are named in the imperative, go to a queue, are processed by exactly one consumer, and the sender usually cares about the outcome. Use an event when the sender is announcing that something has already happened, for example OrderPlaced or PaymentCaptured. Events are named in the past tense, are published to a topic, and the sender does not know or care who reacts. Mixing the two, such as an event that secretly expects one consumer to act, creates hidden coupling.

It depends on the subscription type. With a non-durable subscription, the broker delivers messages only while the subscriber is connected; anything published while it is offline is simply never delivered to it. With a durable subscription, the broker remembers the subscription and stores messages for it while the subscriber is disconnected, delivering them when it reconnects. Shared durable subscriptions, from JMS 2.0, let several consumer instances share one durable subscription. For any subscriber that must not miss events, such as a service updating its own data from OrderPlaced events, durable subscriptions are essential, and their backlog must be monitored.

Ask whether the caller needs the result to continue. If a user is waiting for a price quote or a stock check, call synchronously, with timeouts and fallbacks. If the work can complete later, such as sending a confirmation email or updating a search index, use messaging. Messaging is also the better choice when the work must survive the receiving system being down, when several systems need to react to the same fact, or when load spikes must be smoothed. The cost is eventual consistency and more complex error handling, so do not use messaging merely to avoid designing a good API.

A broker is a stateful, business-critical system that someone must operate. It needs durable storage, clustering and failover, backups, capacity planning and upgrades. It needs security: authentication, authorisation per destination and encryption. Teams need monitoring of queue depth, consumer lag and dead-letter queues, with alerts and runbooks for poison messages. Message formats need versioning and governance, because many systems depend on them. And debugging asynchronous flows requires correlation IDs and distributed tracing across producers and consumers. These costs are worth paying when decoupling is needed, but they should be planned and staffed from the start.

With synchronous calls inside one transaction, a change is either fully visible or not at all. With messaging, each system updates its own data when it processes a message, so the overall system becomes eventually consistent: for a while, the order may be placed but the stock not yet reserved. Intermediate states become visible to users and other services. Messages can arrive more than once or out of order, so consumers must be idempotent and tolerant of ordering. The design must define how long inconsistency may last, how users see pending states, and how reconciliation or compensating actions fix anything that goes wrong.