<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Messaging on Ricardo Zanini</title><link>https://ricardozanini.github.io/tags/messaging/</link><description>Recent content in Messaging on Ricardo Zanini</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 31 Jul 2026 10:40:34 -0400</lastBuildDate><atom:link href="https://ricardozanini.github.io/tags/messaging/index.xml" rel="self" type="application/rss+xml"/><item><title>How Quarkus Flow Talks to the World: The Messaging Architecture</title><link>https://ricardozanini.github.io/2026/07/31/how-quarkus-flow-talks-to-the-world-the-messaging-architecture/</link><pubDate>Fri, 31 Jul 2026 00:00:00 +0000</pubDate><guid>https://ricardozanini.github.io/2026/07/31/how-quarkus-flow-talks-to-the-world-the-messaging-architecture/</guid><description>&lt;p&gt;A workflow engine that can&amp;rsquo;t talk to the outside world is just a fancy state machine running in isolation. The moment you need event-driven orchestration — pausing for a human approval, reacting to an external signal, emitting a domain event — you need a messaging bridge. And building one forces a decision: do you couple to Kafka? AMQP? Roll your own CloudEvent serialization and hope every connector plays nice?&lt;/p&gt;
&lt;p&gt;In &lt;a href='https://ricardozanini.github.io/2026/05/15/what-are-workflows-and-why-do-i-need-them/' target="_blank"&gt;previous posts&lt;/a&gt;, we explored why declarative workflows beat hand-rolled state machines and how Petri net semantics power parallel execution. This post goes one layer deeper: &lt;strong&gt;how Quarkus Flow actually moves events in and out of the engine&lt;/strong&gt;, and why the answer is simpler than you might expect.&lt;/p&gt;</description></item></channel></rss>