> 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-loose-coupling-tight-cohesion.md).
# Event-Driven Architecture: Loose Coupling, Tight Cohesion
An architectural analysis of the balance between technical loose coupling and business cohesion in Event-Driven Architecture (EDA), featuring microservice choreography and event validation workflow de
Many architects describe Event-Driven Architecture (EDA) as a loosely coupled architecture. While this is technically true at the component level, it can be misleading at the business level.
A common misconception is that because services communicate through events rather than direct API calls, they become completely independent. In reality, every business process still depends on multiple services working together to achieve a business outcome.
Think about a person living alone on a remote island. They may appear independent, but they still depend on food, water, shelter, and countless external factors for survival.
### Events are similar.
Individual services may be loosely coupled from a technical perspective, but they remain tightly cohesive from a business perspective. Multiple events and services must collaborate to complete a single business transaction.
There is an invisible line connecting all participating services throughout the business journey. Without the final business outcome, individual events have little value by themselves.
### πAn Online Shopping Example
Consider purchasing a product from an online store.
From a customer's perspective, it looks like a single action:
#### Place Order
Behind the scenes, however, multiple business validations must be completed:
1. Check account balance
2. Verify customer age
3. Determine customer category and applicable discounts
4. Validate daily purchase limits
5. Verify product availability for the delivery location
6. Charge the customer account
7. Send the order to the nearest logistics center
8. Confirm the order to the customer
9. Send notifications through email or SMS
Each step may be implemented by a separate microservice owned by a different team.
**Applying Event Choreography**
In a traditional request driven architecture (RDA), these validations are often executed sequentially, increasing end-to-end latency.
With event driven architecture (EDA), the **OrderPlaced** event can be published to the event mesh or event bus.
Multiple validation services subscribe to the same event and perform their checks independently and in parallel:
* Account Validation Service
* Age Verification Service
* Customer Profile Service
* Purchase Limit Service
* Location Validation Service
Each service publishes its validation result as a separate event.
A decision-making component, sometimes called a **Validation Gate** or **Process Coordinator**, collects the validation outcomes and determines whether the order can proceed.
Once all required validations succeed, a new event such as **Order Approved** is published.
The Account Service then charges the customer, followed by additional events that trigger:
* Logistics fulfillment
* Customer confirmation
* Email notification
* SMS notification
### Loose Coupling vs Business Cohesion
This EDA design has many advantages:
* Services can be deployed independently.
* New validation services can be added without modifying existing services.
* Components can be reused across multiple business processes.
* Parallel processing reduces end-to-end latency.
* Individual services remain technology agnostic.
*
However, the overall business flow is still tightly cohesive.
* βIf the payment fails, the order cannot be completed.
* βIf the validation gate does not receive all required validation results, the process cannot continue.
* βIf the logistics service never receives the fulfillment event, the customer will not receive the product.
The technical dependencies may be removed, but the business dependencies remain.
### The Key Lesson
#### EDA does not eliminate dependency.
Instead, it transforms **explicit technical coupling** into **implicit business cohesion**.
Services become loosely coupled at the implementation level, but they remain tightly connected through business outcomes, event contracts, process orchestration, and event flow dependencies.
The most successful EDA implementations recognize this distinction:
### Events provide loose coupling for systems, but business outcomes create tight cohesion between services.
## π 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 current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/event-driven-architecture-loose-coupling-tight-cohesion.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
