> 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/messaging-troubleshooting/a-missing-event-among-billions-how-we-found-it-on-an-event-mesh/day-10-13-use-case-5-premature-publication.md).
# Day 10/13 Use Case 5: Premature Publication
**The reply event message is published prior to the target event broker receiving the subscription request on DMR.**
We have addressed two issues related to REST-style access, but there is still a small chance of missing an event when transferring it through dynamic message routing across the event mesh. REST-style access follows a stateless design, where multiple threads are created to handle different requests, and each thread needs to retrieve the corresponding reply from the source system.
To tackle this, the publisher initially creates a temporary queue to subscribe to the relevant topic, which includes specific thread instant information (e.g. the thread and instant id). Then, the request event message is sent to other event brokers by the publisher. However, these two actions (sending subscription request and request event message) go through separate communication channels across the event mesh.
As a result, there is a possibility that the source system receives the event message and publishes the reply event message faster than the target event broker receives the subscription request. Since DMR only routes the event message to the event broker that subscribes to it, the reply event message cannot be routed back to the source event broker. This is one of the reasons why using VPN bridging instead of DMR is preferred sometimes.
There are two ways to solve this issue depending on the application logic:\
\*\*Use a static VPN bridge to route the event\
This solution suggests using a static VPN bridge to route the event to the corresponding source event broker, and the event can be directed to the appropriate destination. This approach can help ensure that events are properly routed and delivered to the desired location, including some unnecessary events which meet the routing condition. The bandwidth usage is larger than the DMR.\
\*\*Create a Last Value Queue (LVQ)\
This solution involves setting up an LVQ that subscribes to all reply event messages using wildcard patterns. This helps force the event message to be routed back to the corresponding event broker whatever there is an endpoint to subscribe it or not. By using the LVQ, you can ensure the reply event messages are directed back to the appropriate event broker for further processing or analysis.\
Each of these solutions has its own advantages and considerations. It is important to evaluate the specific requirements and constraints of your application to determine the most suitable approach for addressing event routing and handling issues in your EDA design.
🚀 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/messaging-troubleshooting/a-missing-event-among-billions-how-we-found-it-on-an-event-mesh/day-10-13-use-case-5-premature-publication.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.
