Not every conversation between systems needs an immediate answer.
When a customer places an order, the warehouse does not need to respond within 200 milliseconds. It just needs to receive the order reliably and process it. That is where messaging comes in.
Messaging is one of the oldest ideas in enterprise integration, and one of the most underrated. In my experience, many integration problems that teams try to solve with complicated retry logic around APIs would be solved more simply with a message queue.
What Messaging Is
In messaging, systems communicate by sending messages through an intermediary, usually called a message broker. The sender does not wait for the receiver. It hands the message to the broker and moves on. The broker makes sure the message gets delivered, even if the receiver is busy or temporarily down.
Common brokers include RabbitMQ, ActiveMQ, IBM MQ, Apache Kafka, Anypoint MQ and the messaging services offered by every major cloud.
Queues and Topics
The two basic building blocks work quite differently.
A queue delivers each message to exactly one consumer. It is ideal for distributing work, like processing orders or generating documents, across one or more workers.
A topic delivers each message to every subscriber. It is ideal for broadcasting that something happened, so that many systems can react independently.
Why Messaging Matters
- Decoupling in time: sender and receiver do not need to be available at the same moment
- Resilience: if a consumer fails, messages wait safely until it recovers
- Load leveling: sudden spikes are absorbed by the queue instead of overwhelming a system
- Scalability: add more consumers to process messages faster
The Details That Matter in Production
Delivery guarantees
Brokers offer different guarantees: at most once, at least once, or (in some cases and with care) effectively once. Most enterprise systems use at least once, which means consumers must handle duplicates.
Idempotency
If the same message arrives twice, processing it twice must not cause harm, such as shipping two orders or charging twice. Designing idempotent consumers is one of the most important habits in messaging.
Dead letter queues
Some messages will fail no matter how many times you retry them, perhaps because the data is invalid. A dead letter queue captures these so they can be investigated without blocking everything behind them. Someone must actually watch it.
Ordering
Messages do not always arrive in the order they were sent. If order matters, for example status updates for the same order, you need to design for it explicitly.
Message design
Messages are contracts. Version them, document them and avoid stuffing them with everything "just in case".
Messaging or APIs?
A simple rule of thumb I use:
- If the caller needs an answer now, use an API.
- If the caller only needs to hand off work or announce something, use messaging.
Most healthy architectures combine both.
Final Thought
Messaging is not glamorous. It rarely appears in conference keynotes.
But behind most reliable enterprises sits a well-run message broker, quietly making sure nothing gets lost when things go wrong.