Messaging Fundamentals
Messaging lets software components exchange commands, events, and data through an intermediary channel instead of making every interaction a direct request. It separates producer and consumer timing, but requires explicit contracts, delivery behavior, error handling, and operational evidence.
itDistributed systems, messaging, and integration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Messaging Fundamentals
Messaging is how one component leaves a note for another component without standing in the corridor until it is read. A producer sends a message to a channel or broker. A consumer later receives it and applies an effect. This is useful when intake and processing run at different safe rates, which is a polite way of saying that systems rarely agree on when to be busy.
The important split is between a queue and a topic. A queue gives each work item to one consumer, so competing consumers can share the load. A topic gives every subscription its own copy, so independent consumers can react to the same event. The words are compact; the consequences are not. Pick the shape according to who must act, not according to which label looks more architectural.
A message is also an API. It needs an owner, fields, compatibility rules, identity, correlation, version, expiry, and a data classification. This is the surprise: moving data asynchronously does not make the agreement less strict. It removes the helpful moment when two services can glare at each other over a failed request.
Delivery adds another distinction. At-most-once delivery can lose a message. At-least-once delivery can repeat one. An idempotency key lets a consumer recognize repeated work, so a duplicate delivery does not duplicate an external effect. A successful send therefore proves that the message entered the path, not that the final effect happened. The broker has done its part. The difficult bit has merely acquired a timestamp.
Failures need a route of their own. Limit retries, move persistent failures to a dead-letter path, inspect the cause, then replay or discard deliberately. Queue depth and age show backlog, but neither manufactures consumer capacity. Correlation identifiers, attempt counts, and processing results make the path traceable when the inevitable interesting failure arrives.
Read the intro for the complete component and failure model. Use the slides to compare delivery and distribution shapes. Keep the cheatsheet nearby when choosing contract fields and operational signals. The practice reference and exercise make the route visible in a local broker, which is much calmer than discovering it first in a production incident.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/
Supports
- Message
- channel
- endpoint
- routing
- and management pattern vocabulary
- https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber
Supports
- Publish-subscribe
- subscription
- duplicate delivery
- correlation
- schema
- and backpressure considerations
- https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling
Supports
- Queue buffering
- consumer rate
- backlog
- idempotency
- ordering
- and dead-letter handling
- https://github.com/stn1slv/awesome-integration
Supports
- Messaging ecosystem discovery
- https://www.asyncapi.com/
Supports
- Asynchronous contract tooling
- https://camel.apache.org/
Supports
- Integration routes and components
- https://nats.io/
Supports
- Cloud-native messaging
- https://www.rabbitmq.com/tutorials
Supports
- RabbitMQ work-queue and publish-subscribe practice
- https://www.rabbitmq.com/docs/http-api-reference
Supports
- Local exchange, queue, binding, publish, and retrieval commands
- https://community.ibm.com/community/user/blogs/mayur-raja1/2023/11/29/a-trip-down-memory-lane
Supports
- MQSeries V1 launch in December 1993
- https://docs.oracle.com/cd/E17802_01/products/products/jms/javadoc-102a/javax/jms/Message.html
Supports
- JMS 1.0 date and messaging API milestone
- https://www.rabbitmq.com/resources/erlang-exchange-talk-final/ex
Supports
- RabbitMQ first public release in February 2007
- https://incubator.apache.org/projects/kafka.html
Supports
- Kafka incubation in 2011 and graduation in 2012
- https://www.oasis-open.org/standard/amqp/
Supports
- AMQP 1.0 approval in October 2012
- https://www.oasis-open.org/standard/mqttv3-1-1/
Supports
- MQTT 3.1.1 approval in October 2014
- https://www.cncf.io/announcements/2019/10/28/serverless-specification-cloudevents-reaches-version-1-0/
Supports
- CloudEvents 1.0 milestone in October 2019
- https://stripe.com/blog/idempotency
Supports
- Idempotency keys, retries, exponential backoff, and jitter
- https://kafka.apache.org/
Supports
- Kafka product landscape entry
- https://www.rabbitmq.com/
Supports
- RabbitMQ product landscape entry
- https://aws.amazon.com/sqs/
Supports
- Amazon SQS product landscape entry
- https://azure.microsoft.com/products/service-bus
Supports
- Azure Service Bus product landscape entry
- https://cloud.google.com/pubsub
Supports
- Google Cloud Pub/Sub product landscape entry
- https://www.ibm.com/products/mq
Supports
- IBM MQ product landscape entry
