> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/eda-just-pub-sub.md). # EDA ≠ Just Pub/Sub Demystifying the biggest misconception in modern system design. This technical guide explains why Event-Driven Architecture is far broader than simple Publish/Subscribe messaging, exploring the advanc This article has been published on the [Linedin](https://www.linkedin.com/pulse/eda-just-pubsub-stephen-tsoi-z3upc/?trackingId=BMU5eoyQTgyur5NqX18rIg%3D%3D). ### ⚡ The Hidden Power of EDA: Building Flexible Request/Reply Journeys Through Event Choreography When people think about **Event-Driven Architecture (EDA)**, they often associate it with: * Publish/Subscribe messaging * Asynchronous processing * Real-time event streaming * Event fan-out and distribution However, many real-world business processes are actually initiated through a **request/reply interaction.** What if we could leverage the same event-driven principles to support request/reply scenarios while preserving the core benefits of EDA? ### 🎯 The Challenge In traditional request/reply designs, systems can become tightly coupled through direct service calls, making it harder to scale, evolve, or introduce new capabilities into the workflow. A well-designed **event-driven choreography** offers an alternative approach. It enables an end-to-end business process to flow seamlessly: * Client Request * Backend Services * Multiple Processing Components * Business Decisions * Final Response to Client Regardless of how many systems participate in the journey. As a result, EDA becomes more than a mechanism for event distribution. It becomes a powerful foundation for building scalable and flexible request/reply workflows. ### 💳 Example: Multi-Payment Processing Platform Let's use a payment platform that supports multiple payment methods as an example: * 🏦 Bank Transfer * ⚡ FPS * 💰 PPS * 🔄 EFT Although these payment methods follow different processing paths, they can share the same event-driven framework. #### 📌 Step 1: Establish a Well-Defined Topic Naming Standard The well-defined topic structure with mandatory field and optional field. The mandatory part should include at least four fields: information domain, information subdomain, message type, and schema version.

#### 📌 Step 2: Use the Naming Standard as the Event Flow Guideline * Events may travel through many systems during their lifecycle. * Although different systems may interpret or process the event differently, the original business context must remain intact. * The topic representing the event should remain consistent with the event's original business purpose.

On each event flow, the mandatory parts (red and blue colors) are placed in the message header and brought forward to all subsequent messages in the flow. This part should not be changed throughout the lifetime of the event flow. For each component, the output topic will be the input messages’ mandatory part plus this component function, plus the process status. It is very easy to subscribe to all corresponding events within the same event flow by using a wildcard. ### 🧩 Loosely Coupled Processing Components An important characteristic of this design is that individual processing components do **not contain built-in routing logic**. Each component simply: 📥 Consumes events it is interested in ⚙️ Performs its business function 📤 Publishes the next event The component has no knowledge of: * ❌ Which flow it belongs to * ❌ Which system produced the event * ❌ Which system will consume the next event This significantly improves reusability and maintainability.

✅ The Result This architecture enables a set of **common reusable components** to support multiple request/reply workflows across different channels and payment methods. ### Key Outcomes * Consistent event schema across multiple use cases * All downstream events inherit and extend the original business context * Additional analytical services can be introduced without impacting existing applications * Customer behavior and application activities can be monitored in real time * New processing components can be added or removed easily * Existing applications require no code changes * Most changes can be achieved through topic or queue subscription configuration alone ### 💡 Final Thought One of the biggest misconceptions about Event-Driven Architecture is that it is only suitable for asynchronous event broadcasting. In reality, when combined with strong event governance, consistent topic standards, and event choreography, EDA can also provide an elegant solution for complex request/reply interactions. The result is an architecture that is: * Loosely Coupled * Highly Scalable * Easily Extensible * Business-Driven * Future-Proof ### How does your organization handle request/reply patterns in an event-driven landscape? I'd love to hear your experiences and perspectives in the comments.

## 🚀 Let's Connect Beyond GitBook! If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms: * **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/). * **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/). *** #### 📬 Stay Ahead of the Curve Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week. 👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/eda-just-pub-sub.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.