> 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-governance-the-foundation-of-successful-event-driven-architecture/day-14-14-event-driven-architecture-eda-choreography-design-embraces.md).
# Day 14/14 Event-driven architecture (EDA) Choreography design embraces
Day 14 of 14: Balance decentralized EDA choreography with robust observability by leveraging OpenTelemetry and Trace IDs for end-to-end distributed tracing across complex workflows.
decentralization, fostering asynchronous processing and adaptable steps. Yet, this adaptability can present challenges in tracing and resolving issues within scenarios featuring a multitude of dynamically routed events on a common event mesh. Real-time status updates on message and event delivery to observability tools are pivotal for the seamless execution of EDA.
Organizations are increasingly merging EDA and RDA designs within a unified event flow, leveraging diverse technologies, protocols (such as REST and messaging), and vendor solutions (like APIM and CIAM). Consequently, the intricacy of these designs mandates a robust end-to-end tracing solution to navigate complexities beyond the EDA framework. Open Telemetry, an open standard, emerges as a critical asset in swiftly addressing issues, enhancing performance and cost efficiency in intricate architectural setups, and validating delivery and auditing processes.
For a practical demonstration of implementing end-to-end tracing with Open Telemetry, envision this scenario: A 16-byte trace ID is initiated at the trigger point (mobile app) and propagated across the entire flow through various protocols (e.g., REST, Messaging). Each operation in the flow generates a **unique span ID**, documenting the span ID, input/output time, and **trace ID** in the Application Performance Monitoring (APM) Solution for comprehensive monitoring and analysis. The APM tools links these logs together based on the trace ID and presents the entire flow as a bar chart on the dashboard.
## 🚀 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-governance-the-foundation-of-successful-event-driven-architecture/day-14-14-event-driven-architecture-eda-choreography-design-embraces.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.
