> 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/event-driven-architecture-7-misconceptions-that-architects-still-get-wrong.md).
# 🚨 Event-Driven Architecture: 7 Misconceptions That Architects Still Get Wrong
An architectural guide debunking common misconceptions about Event-Driven Architecture (EDA), covering message broker behaviors, REST integration trade-offs, and async design patterns.
Over the years, through internal training sessions and countless discussions, I have noticed several recurring questions that often lead to confusion about Event-Driven Architecture (EDA). Here are some of the most common misconceptions:
### 1. Does using a message bus mean an application is decoupled?
**No.**
Migrating to a message bus only decouples systems at the communication or geolocation level. True application decoupling requires Event-Driven Architecture, which allows components to be added, removed, or modified independently.
### 2. Does EDA simplify client-side logic?
No.
Asynchronous programming is generally more complex on the client side than synchronous request-response interactions. However, on the service side, EDA simplifies integration logic and can significantly improve performance.
### 3. Is EDA only for messaging technologies?
**No.**
EDA can also be implemented using REST-based approaches. However, doing so is typically more complex and provides fewer performance benefits compared to messaging-based implementations.
### 4. Is EDA tied to a specific event bus product? No.
EDA can be implemented using a variety of event brokers or even a combination of products. The key consideration is how events are distributed and governed, especially when bridging messages across different platforms.
### 5. Can REST be completely replaced by messaging? No.
REST and messaging are complementary technologies.
REST is well suited for non-time-critical operations and cached data retrieval, while messaging is designed for time-sensitive and real-time event processing. In many solutions, both approaches work together as part of a single architecture.
For example, OAuth token authentication typically requires a REST call before establishing a connection to the message bus.
### 6. Are all message bus products push-based and based on persistent connections? No. Push-based products include:
* ActiveMQ
* EMQX
* RabbitMQ
* Solace
* TIBCO
* IBM MQ
**Polling-based products include:**
* AWS SQS
* Azure Queue Storage
* Kafka
In addition, many messaging products support REST interfaces, including Azure Queue Storage, Azure Service Bus, IBM MQ, Kafka, Solace, and TIBCO.
### 7. When should "reply-to" be used to request a response from a consumer?
**Historically, the reply-to pattern was commonly used for isolated components within individual services.**
Today, I generally recommend avoiding **reply-to**. Request/Reply scenarios can be implemented using the Publish/Subscribe (Pub/Sub) pattern, supported by a well-defined topic naming standard and event flow guidelines.
It is also advisable to avoid introducing logic that assumes a component will only participate in a single workflow, as that component may later be reused in other event flows.
EDA is not just a technology choice. It is an architectural mindset that enables greater scalability, flexibility, and resilience.
### 💬 What's the biggest misconception about EDA that you've encountered? Let's discuss 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/event-driven-architecture-7-misconceptions-that-architects-still-get-wrong.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.
