For a complex service that my team and several others maintain, two of my team's applications are called when processing one incoming request. The flow is as follows: an upstream system invokes an HTTP endpoint of our application A, then several other applications managed by other teams are called, one of them publishing an event Topic1 to a message broker that our application B then consumes. B needs to do some extra processing on this event and publish a different event Topic2 to the message broker. The part needed to serve the incoming request (synchronous) ends somewhere between A and B, and the rest is (simplifying) needed for our analytics.
The problem: in order to process the events it consumes, B needs to know some information that is known by A, and that is transient (specific to each request). In the past, we put this information in the response A produces and asked systems in between to forward it to B. But there are several systems and teams involved, which have their priorities and concerns about passing this information, taking several weeks and plenty of discussions.
In summary, we need another way of passing information from A to B, controlled only by our team. What is the best way of doing this? Something we cannot do is having B directly call A (e.g. having A locally store the info and then B fetching it). We are considering these two approaches, but can consider other solutions:
- A publishes an event Topic3 with the needed info, B merges Topic1 and Topic3 by requestId and extracs the info from Topic3
- A writes to a cache that B then queries by requestId