# clemensv/messaging is a curated reading list on async messaging > This repository collects resources on asynchronous messaging and eventing infrastructure, with definitions of the core vocabulary written by the product architect who owns the Azure Service Bus, Event Hubs, Event Grid and Relay platforms. It is a document to read, not a library to install, and the value is in the selection and in the definitions that precede it. **clemensv/messaging** — Resource collection for messaging and eventing - Repository: https://github.com/clemensv/messaging - Stars: 744 · Forks: 60 - Language: Unknown - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/clemensv-messaging ## A document that explains why the links are worth reading The repository is a growing list of resources covering whether and how to use asynchronous messaging and queueing and eventing infrastructures with your applications, and the document says the resources are there for self-study purposes. The important detail is what surrounds the list. The README does not start with links. It starts with a definitions section, and with a short section titled why would I care, which sets out what asynchronous messaging means and why a developer raised on imperative programming has to think differently about it. That framing is what separates this from a link dump. Most collections of messaging links are a pile of vendor blogs and conference talks, and reading them in a random order means absorbing several incompatible vocabularies. This one fixes the vocabulary first, then points at the material. The structure is visible in the navigation line at the top of the document. There are sections for why would I care, definitions of messaging or eventing infrastructure, resources on introductions and patterns, resources on open standards, and resources on products and cloud services. A reader can enter at the point that matches their problem, whether they need the mental model, the specification, or a product comparison. The repository itself is small. The top level holds README.md, an images/ directory, a presentations/ directory and a snippets/ directory, and the primary language of the project is not recorded. This is a documentation repository, and the artefacts are the text and the supporting material. ## The author built the platforms the list recommends The credentials in the README explain the selection, and they are unusually specific. The author is the product architect of the messaging and eventing services in the Microsoft Azure cloud and has helped build these capabilities for over 15 years, starting before the name Azure existed. The team owns multiple hyperscale broker platforms, naming Azure Service Bus, Event Hubs, Event Grid and Relay, which are deployed in hundreds of large clusters in over 70 Azure regions and handle many trillions of requests each day. The same person also lists other Azure capabilities the team invented, prototyped and productized, including Azure IoT Hub, Azure Notification Hubs and Tenant Resource Provisioning, now owned by other teams at Microsoft. The standards work is the other half. The author represents Microsoft on the OASIS AMQP Technical Committee as co-chair, on the OASIS MQTT Technical Committee, in the CNCF Open Telemetry Working Group, in the CNCF CloudEvents and CNCF xRegistry projects, and in the CNCF Serverless Working Group, and was previously on the OPC Foundations Technical Advisory Council and the OPC UA Working Group working on the PubSub specification. Two things follow from that. The products and services section is filtered by someone who has to run these systems at scale rather than by someone who has to market them. And the open standards section covers the specifications the author helps write, so the guidance on AMQP, MQTT and CloudEvents comes from a participant rather than a reader. ## Decoupling, delivery, buffering and network bridging The four properties listed in the document are the core of the argument, and they are worth reading closely because each one is a design decision rather than a feature of a particular broker. Decoupling is first. A system handling work behind a messaging infrastructure can be running at capacity and yet not be overwhelmed, and can even be down while the messaging infrastructure still accepts messages on its behalf. That is the argument for a broker over a direct call. Delivery comes next. You can entrust messages to the messaging system, which will try its best not to lose them, will attempt to deliver them to the right parties, and will retry as often as necessary. Note the phrasing, best and try, since that is a much weaker guarantee than a transactional exactly-once claim, and the document is not pretending otherwise. Buffering is third. A messaging infrastructure is generally great at accepting bursts of messages at once and organising them for later retrieval, with the retrieval happening at the pace the application can handle. The document names this load-leveling, which is a useful piece of vocabulary for capacity planning. Network-bridging is fourth. Messaging infrastructures can often be attached to multiple networks, allowing information to pass between applications in those networks without IP-level connectivity between them. That is the case for a broker in a multi-network architecture, and it is the one that has nothing to do with throughput. ## The postal analogy explains why events and jobs differ The why would I care section uses a physical analogy to explain asynchronous messaging to people who have only written imperative code. The idea is that we all use asynchronous messaging in the physical world. Sending a gift to another city means going to the post office and entrusting the postal service with the package. The postal service takes care of getting it to the destination and also tracks and reports whether the package was delivered successfully. The friend might then call and thank you, but the feedback arrives on a different channel, after however long the handling and delivery took, and usually with a clear reference to the package you sent. The document points out that this is what asynchronous messaging infrastructure does, but for your apps, and it identifies the first giant mental hurdle for developers: we have all been raised on imperative programming models, where a function call causes work and your own code continues only once that work has been reported as done or failed. The definitions section then draws a distinction that is worth the time it takes. A message is an envelope that wraps the content for transfer and carries metadata annotations that help the infrastructure and frameworks route and handle the information, like the addressing information on a postal package. An event is a variation of a message whose content reflects a fact, and a fact is a historical statement about something that happened. The document spells out why that matters: facts can be easily distributed and cached and copied and transformed, because the information they carry will forever be true and never change again. Discrete events are independent of other events, unlike those in a stream, and are usually immediately actionable. A job is the other variation, and it reflects an intent rather than a fact, such as packaging and delivering a purchase order. Getting the job done may involve multiple parties handling parts of it. That is the difference that decides whether you should publish facts or hand out work, and the document argues that these philosophical considerations matter a lot for arriving at smart architectures. ## Producer, consumer, content, and the queue as an exclusive entity The rest of the vocabulary is shorter and is essentially a disambiguation exercise, which is exactly what a reader needs before going into product comparisons. A producer, also called a sender or a publisher, is the role that wants to share or distribute information and therefore produces messages and makes them available through the messaging infrastructure. A consumer, also called a receiver or a subscriber, is the role that retrieves messages from the infrastructure and consumes them, which often but not always means acting on the information. Content, also called payload or body, is the information the producer wants the consumer or consumers to receive and handle, and the document is careful to say it may be any kind of data in any format. The list of names for the infrastructure itself is where the README starts with an explicit admission. Message broker, queue, service bus, event router, event stream engine and event aggregator are all names for asynchronous messaging and eventing infrastructure elements, and the list is by no means exhaustive. Before defining them, the document warns that some of the definitions will be surprising. The queue definition is cut off in the available text, but the fragment given is telling. A queue is a messaging infrastructure entity that assigns the exclusive, which points at the exclusivity property that distinguishes a queue from a topic: one consumer takes the message. The stream and topic concepts follow from the event definition, where discrete events are explicitly contrasted with those in a stream. The rest of the resource list, the introductions and patterns section, the open standards section and the products and cloud services section, is where those definitions get applied. ## What this repository will not give you It is worth being explicit about the limits, because the repository looks like a tool and behaves like a reading. There is no broker implementation here, no client library, no configuration reference and no code you can deploy. The snippets/ and presentations/ directories exist alongside the images/ directory, but the README does not describe what is inside them, so a reader should not assume they contain runnable examples of a working messaging system. The primary language of the project is not even recorded, which is consistent with a repository whose content is prose and images. Nor is there a comparison table with latency or throughput figures. The products and cloud services section points at documentation for specific products, and choosing between them means reading each vendor's own claims, with the usual caveat that the author is an Azure employee and the framing of that section should be read with that in mind. The licence position is also unrecorded. Neither the licence nor a LICENSE file appears in the available description of the repository, so if you plan to copy passages of the definitions into internal documentation, check the terms first. What the repository is good for is orientation and vocabulary. If you already know what a topic is and need to configure one, this is the wrong document. If you are about to design a system where more than one computer does the job, it is a good starting point, because the definitions section will tell you whether you are publishing facts or handing out work, and that decision determines most of the rest of the architecture. ## Conclusion Use clemensv/messaging as an orientation document before you choose a broker, and as a map of the standards to read when you need the specification rather than a blog post, because the definitions it gives for event, job and queue come from someone who has owned the platforms in production for 15 years. Do not expect configuration help, a reference implementation, or reusable code from it, and check the licence position before you copy any of the text. The first thing to read is the definitions section, since the resource list assumes you already agree on what a queue is. ## FAQ ### What is the clemensv/messaging repository for? It contains a growing list of resources covering whether and how to use asynchronous messaging, queueing and eventing infrastructures with applications, and it is meant to be used for self-study. The list is organised into introductions and patterns, open standards, and products and cloud services. ### Who wrote the clemensv/messaging resource list? The author is the product architect of the messaging and eventing services in the Microsoft Azure cloud, with over 15 years building those capabilities, whose team owns Azure Service Bus, Event Hubs, Event Grid and Relay, and who co-chairs the OASIS AMQP Technical Committee. ### How does clemensv/messaging distinguish an event from a job? An event is a variation of a message whose content reflects a fact, a historical statement that will forever be true, so events can be distributed, cached, copied and transformed. A job is a variation of a message whose content reflects an intent, such as packaging and delivering a purchase order, and completing it may involve several parties. ### What are the four properties of messaging infrastructure listed in the README? Decoupling, so a downstream system can be at capacity or down while the infrastructure still accepts messages. Delivery, in which the system tries its best not to lose messages and retries as needed. Buffering, which is called load-leveling and lets bursts be retrieved at the pace the application can handle. And network-bridging, which allows applications on separate networks to exchange information without IP-level connectivity. ### Does the clemensv/messaging repository include runnable code or broker configuration? No. The repository is a document with supporting images, presentations and snippets directories, and it does not ship a broker implementation, a client library or configuration guidance. The primary language of the project is not recorded. ## Sources - [clemensv/messaging on GitHub](https://github.com/clemensv/messaging) - [Issues](https://github.com/clemensv/messaging/issues) - [README](https://github.com/clemensv/messaging/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clemensv-messaging